Guck nächstes mal in die Bildschirmkonsole, da kann man schön sehen was die Image-Installation gerade macht / wo sie hängt
(War zumindest vor einem Jahr noch so)
Nach der Image-Installation hab ich die normale Shell des VPS in der Konsole gesehen, dann über die Konsole den VPS heruntergefahren und ab dann war Schluss, weil der VPS übers SCP nicht ansprechbar war.
Die Installation hat ja an sich ohne Probleme funktioniert, nur das SCP hat Probleme gehabt.
Hatte ich mal. Unter Ubuntu wollte das nicht so recht (allerdings auch bei einem anderen Anbieter). Hab dann bei allen Servern auf die ...::1 gewechselt.
Interessanterweise kann https://mxtoolbox.com/ den rDNS von IPv6-Adressen, die auf :: enden nicht auflösen. Das hat mich anfangs echt verwirrt.
ich hab es zufällig bei einem Server gesehen, dass dessen IPv6 auf :: endet; habe das auf einem meiner vServer mal testweise probiert; überzeugt hat es mich nicht; das mit ...::1 hatte ich bis vor kurzem auch, ich bin zu einer anderen übergegangen: die nach EUI64, welche sich von der MAC-Adresse ableiten läßt;
das ist auch die, welche man braucht, wenn man z.B. einen 6in4-Server hier bei netcup betreibt; Anleitung hier v. x Posts
was anderes:
vorbeischleusen am SPAM-Filter:
falls es jemand mal gebraucht hätte, sowas sucht, oder selbst davor steht das "Rad" neu zu erfinden; es gibt ja mehrere Mglkt.en Mails an einem SPAM-Filter vorbeizuschleusen, und die Gründe sind auch ganz verschieden;
ich hatte das gebraucht, weil die Logwatch-Mails auch Inhalte haben, welche garantiert den SPAM-Filter meckern lassen;
bei mir laufen die alle auf meinen 'Master' - dieser ist mein Mailserver - zusammen, und dort hab ich folgendes ...
der MTA ist postfix und hier die einzelnen Schritte am Mailserver
zuerst in der master.cf folgendes
convert unix - n n - - pipe
flags= user=nobody argv=/etc/postfix/mailcnvt.sh ${sender} ${recipient}(zum mailcnvt.sh Skript später)
/etc/postfix/virtual beinhaltet z.B. das @dns-name-of-server vhost@convert.mail
/etc/postfix/transport das convert.mail convert:
jeweils postmap FILE nicht vergessen
in der main.cf braucht es das:
transport_maps = hash:/etc/postfix/transport
virtual_alias_maps = hash:/etc/postfix/virtual
convert_destination_recipient_limit = 1
bis hier her ist es auf beiden Teilen ident;
bei der empfangenden Stelle braucht man im header_check einen Mechanismus,
welcher genau diese Mails filtert und mittels REDIRECT z.B. nach vhost@convert.mail leitet
z.B. /etc/postfix/hdr_chks.pcre
/^x-base64-mail:[[:space:]]\<root\@dns-name-of-server\>.*$/
REDIRECT vhost@convert.mailin der main.cf braucht es das
header_checks = pcre:/etc/postfix/hdr_chks.pcre
und jetzt zu den Skripten
zuerst auf der absendenden Stelle
#!/bin/bash
EMAIL=$(mktemp)
sleep 1
cat >$EMAIL
(
echo -e -n "From: vHost Local <VHOST-LOCAL@example.net>\n"
echo -e -n "To: VHOST-LOCAL@example.net\n"
echo -e -n "X-Mailer: vHostLocal-Cnvrt/1.1\n"
echo -e -n "Subject: vHost Local Mail\n"
echo -e -n "X-Base64-Mail: <root@dns-name-of-server>\n"
egrep --max-count=1 "^Date: " $EMAIL
echo -e -n "MIME-Version: 1.0\n"
echo -e -n "Content-Type: text/plain; charset=\"us-ascii\"\n"
echo -e -n "Content-Transfer-Encoding: 7bit\n\n"
echo -e -n "-----BEGIN BASE64 MAIL-----\n"
cat $EMAIL |base64
echo -e -n "-----END BASE64 MAIL-----\n"
)|/usr/sbin/sendmail -f VHOST-LOCAL@example.net VHOST-LOCAL@example.net
rm $EMAIL
exit 0auf der empfangenden Stelle ist es deutlich kürzer
(... durch entsprechende Mailadressen ersetzen)
#!/bin/bash
EMAIL=$(mktemp)
sleep 1
cat >$EMAIL
sender=...
recipient=...
sed '1,/-----BEGIN BASE64 MAIL-----/d;/-----END BASE64 MAIL-----/,$d' $EMAIL |base64 -d |/usr/sbin/sendmail -f $sender $recipient
rm $EMAIL
exit 0die Mails einfach verschlüsseln wär auch gegangen,
hat Vor- und Nachteile;
sämtliche Informationen im Mail-Header zwischen meinem Mailserver (netcup) und meinem lokalen Mailserver (VM),
welche ohnehin nicht gebraucht werden, und die Mails nur sinnlos aufblähen werden auf die Art eliminiert;
am vServer brauch ich einfach nur z.B. df |mail root eingeben, und ich bekomm das ungefiltert direkt auf meinem lokalen Mailserver;
vorbeischleusen am SPAM-Filter:
Mein mail filter hat für sowas eine Whitelist.
Warum du sowas aufwändiges machst wundert mich jetzt schon ein bisschen. Du hast doch für deine 10 Korrespondenten eine Whitelist und blockst sonst alles was sich bewegt?
Mein mail filter hat für sowas eine Whitelist.
ja, mein Mail-Zwischenlager aber nicht 
Nach der Image-Installation hab ich die normale Shell des VPS in der Konsole gesehen, dann über die Konsole den VPS heruntergefahren und ab dann war Schluss, weil der VPS übers SCP nicht ansprechbar war.
Die Installation hat ja an sich ohne Probleme funktioniert, nur das SCP hat Probleme gehabt.
Ach so, dann hab ich das falsch verstanden, entschuldige
Hab jetzt unifi controller auf nem VPS laufen. Praktischerweise hinter nem nginx reverse proxy. Aber wie deaktiviere ich den direkten zugriff via port 8433? weil unter domain.de:8433 ist das UI nach wie vor zu erreichen
geekmonkey Auf was greift Nginx intern zu? localhost:8443?
Dann sperr den Port halt am öffentlichen Interface mit der Firewall.
geekmonkey du kannst den auch am PC installieren und dir das Device Passwort merken, falls du später änderst. Der Controller muss nicht immer aktiv sein.
geekmonkey Auf was greift Nginx intern zu? localhost:8443?
Dann sperr den Port halt am öffentlichen Interface mit der Firewall.
Muss man vorsichtig sein, bin ich auch schon drauf reingefallen:
Muss man vorsichtig sein, bin ich auch schon drauf reingefallen:
Wenn das Programm unter Docker läuft, kann der Port doch auch einfach nicht auf dem bridge-Device freigegeben werden oder?
geekmonkey Auf was greift Nginx intern zu? localhost:8443?
Dann sperr den Port halt am öffentlichen Interface mit der Firewall.
Wäre ne Option.
iptables -A INPUT -p tcp -s localhost --dport 8443 -j ACCEPT
iptables -A INPUT -p tcp -s localhost --dport 8080 -j ACCEPT
iptables -A INPUT -p tcp --dport 8443 -j DROP
iptables -A INPUT -p tcp --dport 8080 -j DROPsollte reichen, oder hab ich mal wieder was übersehen?
Bzw. der Controller läuft soweit, wie füge ich denn einen lokalen Unifi AP hinzu? Kann ja schlecht die netzwerkumgebung absuchen haha. Der AP kommt leider erst Montag, kann also noch nicht ausprobieren 
Edit, scheint wohl bequem per App zu gehen, man muss nur zum Controller connecten - eben über Port 443 weil 8433 gedropt wurde ?
Nur mal so als Frage: Jibbet's bei PHP keine Abwärtskompatibilität? Oder was ist der Grund dass manche Leute nach wie vor PHP5 benutzen?
Nur mal so als Frage: Jibbet's bei PHP keine Abwärtskompatibilität? Oder was ist der Grund dass manche Leute nach wie vor PHP5 benutzen?
Linktip: "PHP bricht Abwärtskompatibilität".
Grüße gehen raus an Menschen die RDP Web im Internet hängen haben:
Linktip: "PHP bricht Abwärtskompatibilität".
Habs beim Release schon gefeiert, dass sie sich endlich gegen die ganzen "Alt-Experten", die sich ewig gegen diese Änderungen gestellt haben, durchgesetzt haben und viele Bullshit-Punkte in der Sprache angegangen sind. Es geht endlich in die richtige Richtung.
Für mich leider zu spät. Da es nun .NET Core unter Linux gibt.
Grüße gehen raus an Menschen die RDP im Internet hängen haben:
Du meinst RDP Web Access - ist eine andere Baustelle,
soll heißen, nicht alles macht Sinn, auch per HTTP(S) erreichbar zu haben;
Du meinst RDP Web Access - ist eine andere Baustelle,
Stimmt. Das Web Access hab ich überlesen.
Da ich aber 0 Erfahrung mit dem Controller habe, stellt sich mir die Frage in wie weit ich das Ganze absichern muss? Hätte ungerne ein Einfallstor in mein Heimnetzwerk
Mach den Controller aus, wenn der AP konfiguriert ist. Der AP läuft auch ohne Controller, wenn er einmal eingerichtet ist. 
Mach den Controller aus, wenn der AP konfiguriert ist. Der AP läuft auch ohne Controller, wenn er einmal eingerichtet ist.
Finde einige der Funktionen aber ganz nett xD - Aber hast schon recht, vielleicht gibts nur bei Bedarf nen service unifi start haha
