XRDP mit funktionierenden Copy & Paste Clipboard

Einleitung

In diesen HowTo möchte ich euch zeigen wie ihr Copy & Paste unter Ubuntu, Xubuntu oder Debian zum funktionieren bringt. Die jetzige Version die per APT beziehbar ist  wird kein Copy & Paste bei einer Verbindung von einem Windows Client unterstützt.

Der XRDP Installer von dem Github User scarygliders zieht sich von allen abhängigen Paketen die neuste Version und kompilieren diese einzeln und Installiert diese.

 

Schritt 1 – Installieren der Pakete

Als erstes empfehle ich die Aktualisierung  der Systems.

 

Um XRDP zu nutzen muss eine Oberfläche auf dem jeweiligen Server installiert sein, wenn keine vorhanden ist empfehle ich die Grafische Oberfläche Xfce4.

(Optionale Installation von Xfce4)

 

Damit das kompilieren ohne Probleme verläuft wird es benötigt das dieses Paket installiert wird.

 

Wer kein git installiert hat muss git wie folgt installieren.

 

 

Schritt 2 – Kompilieren der XRDP Pakete

Als erstes muss das Github Projekt auf euren Server Heruntergeladen (geklont) werden.

 

In das Verzeichnis Wechseln

Mit dem nächsten befehl werden die Abhängigen Pakete Heruntergeladen und Kompiliert . Achtung ! Dieser Vorgang kann je Nach CPU Leistung Sehr Lange dauern, bei mir hat es bei meinem AMD OctaCore Server ca. 20 Min Gedauert.

 

Schritt 3 – End Konfiguration

Als Letztes muss ein Eintrag in der .xsession erstellt werden, damit XRDP weiß das ihr die Xfce4 Oberfläche bei X11-XRDP Verbindungen nutzen möchtet. Das muss für jeden User der sich per XRDP Verbinden möchte getan werden.

In meinen Fall tue ich das für den User mit dem ich angemeldet bin.

 

Problem – Hohe CPU Last durch Bildschirm Schoner

Wenn der Bildschirm Schoner(Screensaver) eine zu Hohe CPU Last erzeigt empfehle ich ihn zu Deaktivieren.

 

 

 

 

How to SSH mit Zweifaktor-Authentifizierung schützen

Einleitung

In diesem How To geht es darum wie ihr euren Server mit dem Google Authenticator PAM module für SSH schützen könnt.

Bevor ihr mit der Installation beginnt Installiert euch die Google Authenticator APP, dazu geht ihr mit euren Smartphone auf diese url: http://m.google.com/authenticator

Schritt 1 – Installieren der Pakete

 

Schritt 2 – Konfiguration Anpassen

Öffnen der sshd config

Um das Modul zu aktivieren die in die Erste Zeile einfügen

Als Nächstes wird diese Datei geöffnet

Bei Nano mit STRG+W nach dem Folgenden Text Suchen

und dann das no auf yes ändern, dies sieht wie folgt aus

 

Schritt 3 – Zweifaktor-Authentifizierung Aktivieren

In dem Nächsten Schritt ist es nun möglich die Authentifizierung für einen Benutzer zu aktivieren.

Hierfür muss folgender Befehl eingegeben werden:

Jetzt öffnet sich der Einrichtungs-Assistent der euch einen QR Code  generiert den ihr jetzt mit dem Handy in der Google Authenticator einscannen müsst. Ab jetzt werden von eurer App Codes generiert mit denen ihr euch bei jeden Login authentifizieren müsst.

 

Schritt 4 – SSH Server Neustarten

Als gut erletzt müsst ihr den SSH-Server Neustarten damit die Änderungen an den configs übernommen werden.

Zum Restart des SSH Servers gibt ihr folgendes ein:

 

 

Bei Fragen und Hilfe Stehe ich euch in den Kommentaren zur Verfügung.

 

 

Linux Gameroot 100-1000Hz Kernel

Einleitung

Dieses How To soll erklären, wie man seinen Rootserver zu einem Gameroot macht, der für den Betrieb von Gameservern optimieren ist. Nicht alles ist zwingend. Vieles sind Denkanstöße die man eventuell für sich anpassen muss. Das hier geschriebene wurde mit Linux Debian getestet, sollte aber auch 1:1 mit Ubuntu funktionieren. CentOS mit yum und Suse mit yast2 verwenden andere Paketmanager und die Pakete heißen etwas anders. Hier kann die passenden Namen mit Tante Google, oder dem search Befehl selber herausfinden


Hardware/Leistung bestimmen

Als erstes sollte man sich klar machen, wie viel Leistung und (virtuelle) Kerne man zur Verfügung hat. Diese kann man mit den dem Tool taskset einzelnen Prozessen zuweisen und damit die Prozesse einschränken. Verfügt die Intel CPU über Hyperthreading, wie z.B. bei einem Core i7, hat man doppelt so viele virtuelle Kerne, wie man physische verfügt.
Ruft man das Tool htop auf, kann man sehen, wie viele Kerne vorhanden sind. Falls es nicht verfügbar ist, sollte man es noch installieren

Auf meinem virtuellen Testserver mit drei Kernen sieht es dann so aus, wenn er unter Vollast steht:


Prozesse limitieren

Es ist zwar nicht empfohlen, dass man Gameserver und Webspace auf der gleichen Maschine laufen lässt, für viele ist dies jedoch eine wirtschaftliche Notwendigkeit. In einem solchen Fall kann man die Web- und MySQL bzw. MariaDB Server sowohl in der Anzahl der erlaubten Kerne, als auch in der Priorisierung limitieren.
Gameserver mittels taskset auf einen Kern zu limitieren ist nicht immer förderlich, oft sogar kontraproduktiv.

Zum Einen werden wir mittels taskset die Server auf einen Kern limitieren, zum Anderen werden sie mit nice und ioniceunterpriorisiert. Dabei ist zu beachten, dass taskset bei 0 mit dem Zählen beginnt. Man hat also bei vier verfügbaren Kernen die Kerne 0,1,2,3 zu vergeben.

Um einen Prozess mit niedrigster Priorität auf dem vierten Kern zu starten, stellt man Folgendes vor den eigentlichen Startbefehl

Wir bearbeiten nun die Startskripte im /etc/init.d/ Ordner und fügen den obigen Befehl ein. Bei MySQL bzw. MariaDB ist es das Skript /etc/init.d/mysql, in der man folgende Zeile

mit dieser austauschen muss

Das gleiche Vorgehen mit Apache2. Hier nennt sich das Startskript /etc/init.d/apache2 und die zu ändernde Zeile ist

Nach dem Editieren sollte sie so aussehen

Sobald man mit dem Editieren fertig ist startet man die Server neu

Nun kann man mittels ps die PIDs herausfinden

Und dann mit taskset überprüfen, ob die Änderungen erfolgreich waren. Die affinity list solte den Kernen entsprechen, die man in den Startskripten eingetragen hat.


Netzwerkbandbreite limitieren

Ein weiteres Problem kann die Bandbreite der Netzwerkkarte werden. Die meisten Rootserver verfügen über eine Anbindung von 100Mbit an das Internet. Wenn nun mehrere Leute auf den Seiten Surfen und ggf. auch noch ein Fast Download, oder ähnliches über den Webspace läuft, kann es vorkommen, dass mehr Netzwerkbandbreite angefragt wird, als dem Rootserver zur Verfügung steht.

Um diesen Konflikt von vornherein auszuschließen, kann man beim Apache2 Server die insgesamt zulässige Bandbreite mit dem Modul mod-bw limitieren. Das Modul muss erst installiert werden

Dann aktiviert man es

Als letztes geht man daran, die Bandbreite global zu limitieren. Dazu erstellt man die Datei /etc/apache2/conf.d/throttle-bandwidth und trägt Folgendes ein

Je nach Last können 1000kb und 500kb bereits zu viel sein. Hier gilt es, selber auszuprobieren und den passenden Wert zu finden.

Wenn man die Änderung vorgenommen hat, muss man die Config für den Apachen neu laden


Eigener Gameserver Kernel

Wer sich nicht zutraut, einen eigenen Kernel zu erstellen, der kann sich hier fertige downloaden.

Als erstes bringen wir das System auf den neuesten Stand.

Dann installieren wir die zum Kompilieren notwendigen Pakete:

Durch Abhängigkeiten wird dies eine weit größere Anzahl von Paketen installieren

Wir erstellen ein neues Verzeichnis und wechseln in dieses

Dann werden die aktuellen Kernel Sourcedateien gedownloaded. Hier NICHT Copy & Paste machen, sondern aufkernel.org nachschlagen, was das neueste Stable Release ist.

Die heruntergeladene Datei entpacken und in das Verzeichnis wechseln

Nun weichen wir von den meisten HowTo´s/Tutorials ab und verwenden den make Parameter localmodconfig. Dadurch werden nur die aktuell verwendeten Module und Treiber für den neuen Kernel übernommen. Wer den Kernel ohne Modul Support bauen möchte, der verwendet den verwandten Parameter localyesconfig. Ich bevorzuge die Modulvariante.
Man wird sehr wahrscheinlich eine Vielzahl von Fragen angezeigt bekommen, die man alle mit Enter bestätigen sollte.

Nachdem das Grundgerüst steht, rufen wir die grafische Konfiguration des Kernels auf

Dort folgende Einstallungen vornehmen:
General setup —>
Timers subsystem —>

  • Timer tick handling (Full dynticks system (tickless)) —>
  • [*] Full dynticks system on all CPUs by default
  • [*] Detect full-system idle state for full dynticks system
  • [*] Old Idle dynticks config
  • [*] High Resolution Timer Support

-*- Enable the block layer —>
IO Schedulers —>

  • <*> Deadline I/O scheduler
  • <*> CFQ I/O scheduler
  • [*] CFQ Group Scheduling support
  • Default I/O scheduler (Deadline) —>

Processor type and features —>

  • Processor family (Generic-x86-64 für AMD, Core 2/newer Xeon für Inetl)
  • Preemption Model (No Forced Preemption (Server)) —>
  • Timer frequency (100 HZ) —>
  • Default I/O scheduler (Deadline) —>

Wer möglichst viel auf einer Maschine laufen lassen möchte wählt bei Preemtion Model No Forced Preemption (Server)aus. Wer den genausten Server für z.B. wenige 128 Tick Warserver haben möchte, der nimmt Preemptible Kernel (Low-Latency Desktop). Das Gleiche gilt für Timer frequency. Je genauer der Kernel sein soll, desto mehr HZ sollten eingestellt werden. Große CSS Public Server werden sich hier über den geringeren Overhead von 100HZ freuen, 128 Tick CS:GO Warserver eher über die 1000HZ.

Power management and ACPI options —>
CPU Frequency scaling —>

  • [ ] CPU Frequency scaling

-*- Networking support —>
Networking options —>

  • [*] Network packet filtering framework (Netfilter)
  • [*] QoS and/or fair queueing

Netfilter sind die IPtables. Diese braucht man nicht zwingen. Jedoch wird man als Betreiber von Gameservern früher, oder später von einem DOS, oder sogar DDOS betroffen sein. Während man gegen letzteres auf dem eigenen Root nicht viel machen kann, kann man einen DOS mittels IPtables filtern. Dafür muss der Support dann im Kernel compiliert sein.
Mittels QoS (Quality of Service) kann man Traffic kategorisieren und priorisieren. Man kann Down und Uploads hinter Gameservertraffik hinten an stellen.

Nachdem alle Einstellungen vorgenommen sind, beenden und speichern wir die Konfiguration und machen uns an das eigentliche Kompilieren.

Wenn der Compiler erfolgreich durchgelaufen ist, sollte sich im Order /root/kernel/ der fertige Gameserver Kernel samt Header Dateien als .deb Pakete befinden. Diese installieren wir mit dem Tool dpkg. Auch hier bitte gucken, dass man nicht einfach Copy & Paste betreibt, sondern vorher schaut, wie der Kernel eigentlich heißt.

Nachdem der Kernel installiert ist, bleibt nur noch das Rebooten:

Je nach Leistungsstärke des Servers, sollte dieser in einer, oder etwas mehr Minuten wieder erreichbar sein. Mit dem Tool uname kann man überprüfen, ob der neue Kernel geladen wurde


IPTables/Firewall

In meinem Github Repository befindet sich ein fertiges Skript für die IPTables. Je nachdem, welche Ports man belegt hat, muss man es noch anpassen.
Es sollte in der Lage sein, gängige Arten von DOS Angriffen abzufangen.

Teamspeak 3 Ports werden an dieser Stelle aufgelistet

Gameserver sind hier zu finden

Je nach Traffikaufkommen, kann das Syslog sehr schnell anwachsen. In diesem Fall folgende Zeilen auskommentieren