Leider etwas verspätet aber dennoch hier nun der Artikel zum Upgrade auf Proxmox 4.
Ich gehe von meinen Erfahrungen während des Upgrades aus und gebe diese hier nur weiter.
Die größte Veränderung ist wohl der Wegfall von OpenVZ und ein Switch zu LXC Container. Das bringt ein paar Vorteile aber auch einige Nachteile mit sich die den Konfigurationsaufwand deutlich erhöhen. Es ist allerdings alles lösbar und durch den höheren Aufwand sollte man sich nicht abschrecken lassen.
Einen Zwischenbericht muss es noch geben. Stundenlang war ich auf der Suche wie man im Proxmox 4 einen LXC Venet Container einrichten kann so wie es im Proxmox 3 möglich war.
Da Proxmox 4 generell nur Bridged Networking unterstützt und daher alles über die Bridge gehen muss, war das gar nicht so einfach. Ich hab es mit einer virtuellen Alias Schnittstelle probiert und die Bridge einfach gelassen, ging nicht. Die virtuelle Schnittstelle wurde einfach zuspät geladen und somit musste auf dem LXC Container jeder Dienst neu gestartet werden um auf der Public IP zu lauschen. Dann habe ich alles mögliche probiert bis ich letztendlich bei einem NAT gelandet bin. Das war bis DATO die einzige Möglichkeit eine zusätzliche Public IP OHNE weitere MAC Adresse zum Laufen zu bringen. Zusätzliche MAC Adressen werden nämlich von meinem (und auch den meisten anderen) Anbieter blockiert. Dann kam mir allerdings tatsächlich die Lösung ohne NAT um LXC Venet mit weiterer Public IP zum Laufen zu bekommen.
Die Proxmox 4 Installation ist relativ einfach. Ich beschreibe hier mal trotzdem die zwei Wege die am häufigsten Vorkommen. Vielleicht hilft es dem ein oder anderen, vielleicht braucht es auch niemand aber der Vollständigkeit halber habe ich es hier erklärt.
In meinem Beispiel verwende ich Debian 8, da es das aktuelle Stable ist.
Die Überschrift sagt eigentlich alles!! Ein nerviger Apparmor „Fehler“ den man getrost loswerden kann. Hier steht wie es geht!
Das Proxmox 4 Released wurde ist ja nichts neues mehr. Ich muss gestehen, dass ich Proxmox 4 eine Weile gemieden habe. Es wurden so viele Sachen verändert, dass es unklug in einer produktiven Umgebung wäre so früh zu switchen.
Zumal das ja ein nicht gerade unerheblicher Aufwand ist. Aber dazu in einem späteren Artikel etwas mehr. Hier geht es jetzt um die Aktivierung des TUN/TAP Devices für eine VPN Verbindung.
Wie versprochen gibt es heute eine weitere Anleitung und zwar mit Nginx 1.8.0 als Reverse Proxy.
Ich muss ehrlich gestehen, dass ich von Nginx fast mehr begeistert bin als von Squid3 aber das liegt vermutlich nur an den gewohnten Konfigurationen.
Aber was ist Nginx eigentlich? Nichts weiter als ein Webserver wie auch Apache und Co. Nur eben schneller und dabei verbraucht er deutlich weniger Ressourcen als Apache. Selbst 10000 Request pro Sekunde machen Ihm nicht wirklich was aus. Dazu könnt Ihr euch bei Wikepedia und auf der Projekthomepage mehr durchlesen.
Heute gibt es mal wieder eine Anleitung zu einem Thema was mich selbst gerade beschäftigt hat. Ein Reverse Proxy um die Last von den Webservern zu nehmen und dadurch einiges an Performance zu gewinnen.
Aber was ist ein Reverse Proxy eigentlich?
Ich versuche es mal so einfach wie möglich auszudrücken.
Ein Reverse Proxy ist eine Schnittstelle die mit dem Internet verbunden ist wie ein Webserver. Der Unterschied ist, dass die Anfragen (sofern der Proxy keinen Cache hat) an einen anderen Server weitergeleitet werden der keine öffentliche IP benötigt. Das kann also durchaus ein privater Server in einem privaten Netzwerk oder einem VPN Netzwerk sein. Dabei kann der Proxy die Anfragen auf mehrere Server verteilen. Man kann also hinter einer Domain auch 20 Server haben die alle Anfragen bedienen. Vorausgesetzt es ist auch auf allen Servern der gleiche Inhalt vorhanden.
x2Go klingt erstmal relativ unspektakulär. Hinter diesem Namen verbirgt sich jedoch eine coole grafische Oberfläche die auf ziemlich jedem Linux PC installiert werden kann und damit eine Remote Desktop Umgebung bereitstellt.
Das coole daran ist, dass die Verbindung über eine SSH Session aufgebaut wird und somit die Verbindung bereits verschlüsselt wird und man nicht einfach „übernommen“ werden kann. Man muss also nicht extra noch eine VPN Verbindung herstellen um eine sichere Remote Verbindung zu erhalten. Ein sehr großer Vorteil im Vergleich zu anderen Remote Lösungen!
Man kennt es ja, man braucht irgendwo für irgendwas einen flexiblen Slider, ohne gleich tausende Plugins irgendwo installieren zu müssen.
Dafür habe ich einen HTML5 Slider gebaut, der in jede Webseite mit einem einfachen HTML Code eingebaut werden kann und stelle diesen gern zur Verfügung.
Auf einem Server von mir habe ich das Problem, dass hin und wieder einige Packets Loss oder sehr lange Antwortzeiten zustande kommen und der Server einfach nicht nach außen durchkommt. Das ist bei einem Monitoring System natürlich sehr „bescheiden“.
Da mein Monitoring System extern bei Linevast steht und diese Probleme nur von diesem Server zu beobachten sind, ist die Vermutung natürlich ganz klar. Ein Netzwerkproblem bei dem externen Server.
Nun, egal wo, wird die erste Aussage sein: „Machen Sie einen mtr sobald das Problem auftritt“.
Irgendwie auch verständlich, wenn auch sehr ärgerlich. Ist ja schließlich nicht die Aufgabe des Kunden zu sagen wo der Fehler auftritt.