Da wir das Thema ja mal vor drei Ewigkeiten hier hatten - mein Shiftphone ist da. Ich hab auch schon ein Magisk gepatchtes ShiftOS Lite draufgezaubert. Aber erstmal richte ich das Ding richtig ein.
Dann werde ich später sicher auch nochmal einige Worte dazu verlieren. Es hatten sich ja einige interessiert... 
Dumme Frage:
Wie schätze ich meine IT Kenntnisse richtig ein?
Hintergrund:
Ich komme aus einer etwas anderen Branche, hab mir eigentlich alles selber beigebracht und würde wenn irgendwie möglich gerne die Branche wechseln.
So dumm ist die Frage garnicht...
Wir haben in der Ausbildung auch in einem Intranet Tool so eine Karte mit hunderten Themen, wo wir uns auf einer Skala von glaube 1-9 einschätzen sollen - meine Frage war dann am Anfang so: "Na an was soll ich mich denn da orientieren, wenn ich mich einschätze?" - konnte mir keine so wirklich sagen. Es blieb dann bei einem "Na nirgendwo dran, halt so wie du denkst."
Die Frage ist halt - wo willst du in der IT hin? Dahingehend musst du dich dann natürlich etwas einschätzen. Ein Plattform Betriebsführer braucht z.B. eher nicht so die krassen Programmier-Skills, wie ein Entwickler.
Evtl. kannst du uns ja sagen, welche Bereiche der IT dich so am meisten interessieren und was du dir so vorstellst. Und dann erzählst du mal, was du in diesen Bereichen schon so kannst und gemacht hast. Also zusammengefasst. Dann könnten wir das ja mal versuchen, für dich einzuschätzen. Nur so eine Idee...
Zwar nicht das Speichermedium mit den Daten, aber das RootFS.
Nächstes mal redundant bauen? Oder woran liegt es?
WHAT?
Hier fällt gerade mein Weltbild zusammen 
das ist doch eine offizielle Regel, da gibt es doch gar kein wenn und aber, oder? 
Wusstet ihr, dass man Punkt vor Strich Rechnung nur in der Wissenschaft und nicht im Alltag praktiziert? Also ich nicht, Microsoft scheinbar schon... 
Am besten nochmal einen Speedtest mit wget (zumindest mal Download)
Valkyrie Große Dateien findest du hier.
Falls es da auch Probleme gibt, kann ich dir gerne auch nochmal ein Testfile von meinem RS aus zur Verfügung stellen.
Steal siehst du übrigens immer erst bei Last. Kurz gesagt: Wenn der Server keine/kaum Rechenleistung beansprucht, meckert das OS auch nicht, wenn ihm welche weggenommen wird. 
Wenn die VPS im Leerlauf sind, haben die nicht viel mehr Steal als ein RS. Aber beim RS bleibt das bei steigender Last so, beim VPS nicht.
EDIT: Datenleak bei Buchbinder - was sind das denn immer für Desateur-Admins? Sowas prüft man doch und sowas fällt einem doch auf... grrr. Wie fahrlässig kann man denn bloß handeln? Hauptsache es funktioniert irgendwie? Meine Güte... solche Leute regen mich echt auf.
Haben wir hier Nutzer von QubesOS, die man mal ein bisschen mit Fragen löchern könnte?
@03simon10 Prinzipiell könntest du vielleicht auch die RAM Riegel herausnehmen, den Gewichtsunterschied von der Packung mit Erde wieder ausgleichen und die Packung dann zurückschicken. *hust* 
(rel https://www.computerbase.de/2019-08/amazon…bwicklung-erde/)
Da wir ja hier mit Sicherheit einige Leute haben, die eine Nextcloud betreiben und vielleicht auch die News App benutzen.
Die News App stellt eine spezielle Situation dar, da hier Daten von überall nachgeladen werden. Mindestens ein Favicon jedes RSS Feeds.
Wenn man Feeds von Blogs und Co abonniert hat, dann werden nicht selten auch Sachen aus CDN's, YouTube, Google Fonts und aller möglicher anderer Mist nachgeladen.
Im Normalfall bringt Nextcloud eigene, recht gut funktionierende Content Security Policies mit. Bei der News App kann man das allerdings vergessen - datenschutztechnisch ein totaler Krampf. Ublock regelt zwar, zerstört dabei aber zum Teil das Layout der News App.
Mein Tipp daher: gezielt nur die CSP von der News App überschreiben. Das sieht dann in einem nginx reverse Proxy bspw. so aus:
location / {
[...]
proxy_pass http://[fd00:21:1::111]:80/;
[...]
}
location /index.php/apps/news/ {
[...]
proxy_pass http://[fd00:21:1::111]:80/index.php/apps/news/;
[...]
proxy_hide_header Content-Security-Policy;
add_header Content-Security-Policy "frame-ancestors 'self'; default-src 'self'; img-src 'self' data:; object-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-eval' 'unsafe-inline';" always;
}Falls jetzt mimimi kommt: Natürlich sind dann alle Bilder weg. Damit kann man aber leben, wenn man Wert auf Datenschutz legt.
EDIT: Ich weiß allerdings nicht, wie sehr sich die Android App für CSPs interessiert...
Ein großes "Uff" für Grafana. Error 404 aber trotzdem das ganze als Statuscode 200 ausliefern. Was soll sowas? 
Vielleicht hilft das: http://nginx.org/en/docs/http/…ml#proxy_intercept_errors
Yeah! Das hat jetzt endlich das gewünschte Ergebnis gebracht! Danke!
Und perryflynn - das Repo verkleinern mit bfg hat nach ein paar Startproblemen dann auch geklappt. Gitlab zeigt es zwar immer noch als ca. 40 MiB groß an, aber wenn man es klont, dann ist es bloß 4-6MiB (bzw. entpackt 12-13MiB) groß. So soll es sein! Danke! 
Okay. Ich habe mir deine Konfiguration nochmal angesehen. Du verbindest dich mit deinen Containern per https:// - das macht so nur wenig Sinn, behaupte ich mal. Du möchtest dich viel eher über http:// auf Port 80 verbinden (siehe meine Konfiguration).
Sollte ein Container bzw. die Applikation nur über https:// erreichbar sein, dann verwendet diese vermutlich ein selbst signiertes SSL Zertifikat. Probier mal, die Container entweder per http:// mit Angabe von Port 80 anzusprechen oder per https:// und setz dann noch die Einstellung "proxy_ssl_verify off;"
So. Das mit dem $upstream_status funktioniert leider nicht. Ich arbeite aber auch mit normalen proxy_pass und nicht mit Upstream oder so.
Naja. Dann gehts halt nicht - tut mir nicht weh, wäre nur ein nettes Feature gewesen.
bfg habe ich mir angeschaut. Werde das morgen auf Arbeit mal am verunfallten Repo testen, theoretisch könnte ich ja dann direkt den phpmyadmin Ordner raushauen. Das könnte gehen...
Nochmal kurz um dein Setup zu verstehen. Du hast einen Proxmox Host, einen nginx Container und einen/mehrere Webapp Container?Oder nginx direkt auf dem Proxmox Host?
Hast Du da nen Tipp?
Die Wireguard-eigene Dokumentation ist gut. Ansonsten musst du dich halt etwas zu iptables usw belesen, um das NAT nach außen + das Forwarding zwischen den Netzen zu gewährleisten.
Ich guck mal wie ich voran komme, erstmal noch ein nextcloud aufsetzen, ich will meine daten vom webhosting umziehen.
Schalt bitte einen Gang zurück und ziehe keine produktiven Anwendungen/Daten auf einen Server bzw. Proxmox Host um, den du gerade noch aufbaust. Das ist ein Sicherheitsrisiko für deine Daten und du bist dann gezwungen, den Server laufen zu lassen.
So kannst du sagen "Okay, ich weiß nicht, ob das stabil läuft und sicher ist, also fahr ich den Server runter und mach morgen weiter." - das geht nicht, wenn er in dieser Aufbauzeit schon produktiv läuft.
$upstream_status?
http://nginx.org/en/docs/http/n….html#variables
Ansonsten könnte der Upstream auch einen Header mit weiteren Informationen zurück geben. Dann könnte man noch etwas besser filtern und drauf reagieren. Geht natürlich nur, wenn Du einfluss auf das Backend hast.
Klingt sinnvoll - teste ich dann mal, wenn ich zuhause bin.
Andere Frage... ich hatte letztens einen kleinen "Git Unfall" - ich habe ausversehen einen commit mit phpmyadmin drin gemacht. Ich hatte das phpmyadmin zwar danach wieder gelöscht (git rm) und neu commitet, aber das phpmyadmin hängt jetzt noch irgendwo im .git Ordner drin, wodurch der verdammt groß ist.
Ich suche jetzt nach einer Möglichkeit, den "verunfallten" commit (mittlerweile sind schon wieder gut 20 Commits dazu gekommen) da irgendwie aus dem Verlauf rauszuholen. Ich werde nur nicht so recht fündig. Mit git rebase soll das wohl irgendwie gehen, aber ich steige da noch nicht so ganz durch... kann mir jemand sagen, wie man sowas macht? Ich will jetzt ungern experimentieren und mein Repo dabei zerlegen, das wäre echt ärgerlich. 
Die 404 kommt ja nicht vom Proxy, wenn der Service dahinter ein File nicht findet.
Genau darauf wollte ich ja hinaus. Das ist mir durchaus bewusst.
Ich suche so etwas ala:
if ( $backend_response_code == 404 ) {
return 444;
}
Ich möchte also quasi auf Basis der Antwort des Services im Backend die Antwort manipulieren bzw. in diesem Fall unterbinden. Nur ich finde halt nichts dazu bzw. weiß nicht, wie das geht.
try_files $uri =444;
Genau das geht eben nicht.
Meine Proxy config ist z.B. folgende:
location /public/ {
include vhost.d/subconfigs/botcheck_storage.conf;
include vhost.d/subconfigs/proxy_header.conf;
auth_basic off;
proxy_pass http://[fd00:21:1::110]:80/public/;
}
location / {
include vhost.d/subconfigs/botcheck_storage.conf;
include vhost.d/subconfigs/proxy_header.conf;
auth_basic "Restricted Area";
auth_basic_user_file passwd/htpasswd_storage;
proxy_pass http://[fd00:21:1::110]:80/;
}Egal ob das von dir genannte in den location Blöcken, oder außerhalb der location Blöcke steht - es kommt ein normaler 404er zurück.
Bzgl. des Scripts schaue ich dann mal, was ich machen kann.
Andere Frage bzw. andere Thema.
Wie kann ich bei nginx (als reverse Proxy) konfigurieren, dass er statt einem Statuscode 403 oder 404 Statuscode 444 bzw. nichts ausliefert?
Ich probiere es gerade mit error page und location, aber das scheint bei reverse Proxy nicht zu gehen... aber aus dem Internetz werde ich auch nicht so recht schlau.
Moin.
Bei mir läuft ein ähnliches Setup. Ich distanziere mich allerdings von fertigen Images - bau es lieber selbst auf, da weißt du, was du hast und vor allem ist ein Lerneffekt da.
Ich habe einen Server mit einer IPv4 und einer IPv6. Die Firewalls von Proxmox sind überall aus, ich mache mein Firewalling selbst mit iptables.
Ich habe einen nginx Container und mehrere Container mit diversen Webapps.
Per iptables auf dem Proxmox Host mache ich also ein Portforwarding von Port 80/tcp und 443/tcp auf den nginx Container.
Dieser splittet dann je nach Domain auf und leitet den Traffic an den entsprechenden Container mit der Webapp an.
Also wenn ich jetzt meinen Container per cloud.domain.tld anspreche, werde ich mit dem Nextcloud Container verbunden und wenn ich ihn per monitoring.domain.tld anspreche, dann mit meinem IcingaWeb.
Hier sind mal meine nginx Konfigurationen für meine Nextcloud. Die kannst du dir eigentlich zum Vorbild nehmen. Das SSL arbeitet mit einem ECDSA (ec-384) Zertifikat und mit OCSP must staple. Das musst du bei der Zertifikatsanfrage in acme.sh mitgeben. Wenn man mit OCSP arbeitet, muss man auch OCSP Caching betreiben, sonst kann es zu nervigen Fehlermeldungen im Browser kommen. Mehr Infos hier.
server {
listen 80;
listen [::]:80;
server_name cloud.meinedomain.tld;
include vhost.d/subconfigs/http_redirect_acme.conf;
}
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name cloud.meinedomain.tld;
location / {
include vhost.d/subconfigs/botcheck.conf;
include vhost.d/subconfigs/proxy_header.conf;
proxy_pass http://[fd00:21:1::111]:80/;
proxy_buffering off;
proxy_request_buffering off;
client_max_body_size 50G;
}
location = /.well-known/carddav {
return 301 $scheme://$host/remote.php/dav;
}
location = /.well-known/caldav {
return 301 $scheme://$host/remote.php/dav;
}
# standard SSL config
include vhost.d/subconfigs/ssl_standard.conf;
# custom ssl config
ssl_certificate /etc/acme_letsencrypt/cloud.meinedomain.tld/fullchain.pem;
ssl_certificate_key /etc/acme_letsencrypt/cloud.meinedomain.tld/privatekey.pem;
ssl_stapling_file /etc/acme_letsencrypt/cloud.meinedomain.tld/ocsp.der;
ssl_trusted_certificate /etc/acme_letsencrypt/cloud.meinedomain.tld/chain.pem;
# header
add_header Expect-CT "enforce; max-age=21600;" always;
}# acme challenge config
include vhost.d/subconfigs/acme.conf;
# redirect all HTTP requests to HTTPS with a 301 Moved Permanently response (if its not a bot)
location / {
include vhost.d/subconfigs/botcheck.conf;
return 301 https://$host$request_uri;
}# send no answer if a bot user agent is asking
if ( $is_bot ) {
return 444;
}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_cookie_path / "/; secure; HttpOnly; SameSite=strict;";# standard SSL config
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256;
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:50m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains" always;
resolver [fd00:21:1::103] valid=300s;acme.sh sollte man übrigens nicht unbedingt als root laufen lassen...
Es empfiehlt sich auch, auf dem Proxmox Host noch ein Wireguard VPN aufzusetzen und zwischen diesem und der Bridge zu routen/forwarden. Das hat den Vorteil, dass du SSH Ports, phpMyAdmin, Webmin, Shellinabox usw usw nicht von außen zugänglich machen musst. Das erhöht den Bedienkomfort und die Sicherheit erheblich.
Wenn du noch Fragen hast, dann stell sie mir bzw. uns gern.
Das ist keine gute und zuverlässige Option zu prüfen, welcher Webserver eigentlich genutzt wird.
Alternative? Prozesscheck? Oder ein Check auf die Binary?
Kritik ist das eine und auch kein Problem - aber dann sag mir bitte auch, was ich besser machen kann. Danke!