Gitea Update

Gitea ist im Grunde etwas wie GitHub, nur selbst gehostet. (Ähnlich zu GitLab nur nicht so intensiv im Verbrauch von RAM und CPU)

Gitea ist ein Fork von Gogs – allerdings mit einer offeneren Mentalität der Community als Gogs …

Nun verwende ich diese Software auf einem meiner Server und wollte es heute aktualisieren. Bei einer „normalen“ Anwendung klickt man dazu einfach auf einen Button wie „Update suchen“. Leider gibt es diesen Button bei Gitea aktuell nicht.

Was also tun?

Ich habe das gemacht, was man an der Stelle wahrscheinlich oft als Erstes macht: Googeln!

Google brachte mir das Ergebnis: https://geeklabor.de/archives/207-Gitea-source-update.html

Dieses Ergebnis brauchte mich aber nicht weiter, da ich nicht einmal die Programmiersprache Go auf meinem System installiert hatte … (Ich erwähne es hier trotzdem, vielleicht hilft es ja jemand weiter ….)

Die Lösung!

Ich hatte Gitea als Binary auf meinem Server installiert. Gitea bietet auf GitHub neue Versionen auch als Binary an.

Die Lösung war also recht einfach: Neue Binary mit wget ziehen, mit mv umbenennen, die Berechtigungen mit chmod und chown ändern und wie gewohnt ausführen!

Vor solchen Updates sollte man übrigens mit ./gitea dump eine Sicherung erstellen …

Tutorial: Einen Debian Server absichern

In letzter Zeit werden immer wieder Server für Projekte von „Wronnay“ eingerichtet. Um das Ganze etwas bequemer zu machen, wurde von mir ein Bash-Script erstellt, dass die Grundeinrichtung etwas vereinfacht. Ich möchte jetzt eine kleine Anleitung veröffentlichen, die die Verwendung dieses Scripts erklärt.

Informationen über das Script:

  • Es steht unter der GNU General Public License
  • Es aktualisiert die installieren Pakete
  • Es installiert folgende Pakete: ufw rkhunter fail2ban nano sudo htop whois
  • Es setzt einen Cronjob für tägliche Paket-Updates
  • Es erstellt eine Grundkonfiguration für die Firewall „ufw“
  • Es erstellt einen neuen Benutzer
  • Der Standard-Port für SSH wird geändert und der Login mit dem „root“ – User verboten

Verwendung:

Bevor das Script heruntergeladen werden kann, müssen erst die nötigen Pakete zur Verwendung installiert werden:

Zuerst benötigen wir Root-Rechte:

su

Jetzt installieren wir die benötigten Pakete:

apt-get install nano git

Nun können wir das Script downloaden:

git clone https://github.com/CMiksche/DebianServerBasicConfig.git

Anschließend wechseln wir in das Verzeichnis:

cd DebianServerBasicConfig

Und geben in der config.sh – Datei unsere gewünschten Daten (Benutzername, Passwort, SSH-Port) ein:

nano config.sh

Nach dem Abspeichern der Datei geben wir der Install-Datei noch die passenden Rechte:

chmod 0777 install.sh
chown root install.sh

So. Jetzt können wir die Datei auch ausführen:

./install.sh

Danach müssen wir nur noch das Script löschen:

cd ..
rm -R DebianServerBasicConfig

Fertig. Bei dem nächsten Einloggen über SSH ist jetzt nur noch zu beachten, das man den neuen Port, Benutzer und das neue Passwort verwenden muss.

Server: Umzug

Der Server, der 2014 für die meisten Projekte verwendet wurde, wird jetzt nicht mehr verwendet. Im Januar sind die ersten Projekte des alten Servers auf einem neuen umgezogen und die restlichen Projekte sind in den letzten Tagen auf einen anderen, neuen Server umgezogen.

Die zwei neuen Server haben jeweils mehr Leistung als der alte Server. Der Standort (Frankfurt am Main) bleibt und auch sonst hat sich nicht viel mehr geändert, außer dass jetzt mehr als die doppelte Leistung des alten Servers verfügbar ist.

Insgesamt werden im Netzwerk von Wronnay.net 4 Server in 3 Ländern verwendet.

Vorübergehender vierter Server

Bis Ende Januar wird ein vierter Server getestet, wenn dieser die Anforderungen erfüllt, wird vermutlich ein Umzug einiger Webseiten auf den Server stattfinden und dafür ein anderer Server eingestellt werden.

Es wäre sogar möglich, dass der teuerste Server abgeschafft wird und dafür zwei kleinere angeschafft werden.

Der dritte Server nimmt in den USA seinen Betrieb auf

Zur Erweiterung und Unterstützung des Netzwerks nimmt ab heute der dritte Server in den Vereinigten Staaten seinen Betrieb auf.

Daten von Besuchern und Kunden bestehender Wronnay.net – Dienste werden wohl nicht auf den Server in den USA kommen, sollte es aber z.B.: durch eine erhöhte Ausfallquote der ersten beiden Server nötig sein, werden diese benachrichtigt.

VServer Nummer 2.

Ich habe heute die Zugangsdaten für meinen lang erwarteten, zweiten virtuellen Server erhalten. Der neue Server steht in Frankreich und war von mir schon lange erwünscht, da er mein bisheriges Netzwerk erweitert und auf ihm mein neues (derzeit noch in Entwicklung befindliches) Werbenetzwerk laufen soll.

Ich habe jetzt alles, was ich brauche, damit ich meine Firma anmelden kann. Jetzt muss ich nur noch ein bisschen programmieren, einrichten und zum Notar, zum Handelsregister, zum Finanzamt und zur Meldebehörde gehen.

Hoher RAM-Verbrauch

In den letzten Tagen waren meine Webprojekte nicht so gut erreichbar. Das lag an einem sehr hohen RAM-Verbrauch meines Servers.

Woran das genau lag, weiß ich nicht. Trojaner / Rootkits und Viren habe ich keine gefunden. Es könnten einfach zu viele Besucher gewesen sein. (Da ich nicht von allen Webseiten Statistiken anlege, weiß ich bei manchen Projekten von mir die Besucherzahlen gar nicht)

Da meine Dienste auch in Zukunft gut erreichbar sein sollen, habe ich meinen Anbieter kontaktiert und ich werde wahrscheinlich entweder auf einen leistungsfähigeren Server wechseln oder meine Projekte auf mehrere Server aufteilen.

Update: Ich habe das Problem ermittelt: Mein Virenscanner (ClamAV) sorgte für den hohen Verbrauch meines Arbeitsspeichers. – Ich werde wohl einen anderen Virenscanner nutzen und ClamAV nur manchmal nutzen …

Mein (v)Server war offline …

Leider waren heute meine gesamten Dienste (bzw.: Webseiten) aufgrund eines Serverausfalls nicht mehr erreichbar.

Deshalb bin ich am Überlegen, ob ich mir vor der Gründung einer Firma nicht noch einen vServer von einem anderen Anbieter zulege. Möglich wäre auch ein vServer aus dem Ausland (z.B.: USA), da ich dann unabhängiger bin: Selbst wenn es in Deutschland aufgrund von politischen oder technischen Gründen Ausfälle gäbe, wären noch ein paar meiner Dienste im Ausland erreichbar.

Der Ausfall meines vServers …

Gestern Abend ging es los: mein vServer und somit alle meine Webseiten mit Top-Level-Domains, war nicht mehr erreichbar. Also habe ich versucht, meinen Server neu-zu-starten, aber das ging nicht. Daraufhin habe ich im Kundenbereich meines Anbieters ein Ticket erstellt und ihm mein Problem erklärt. Heute um 11:54 meldete darauf mein Anbieter auf Twitter, dass es eine Störung gäbe und um 12:28 wurde die Störung behoben. Weil ich allerdings schon am Vorabend CloudFlare eingeschaltet hatte, ist mein System allerdings (schon wieder) nicht mit CloudFlare zurecht gekommen. So musste ich CloudFlare deaktivieren und meinen Server neu-starten. Aber das ist noch nicht alles: da ich danach feststellen musste, dass mein Dashboard von WordPress weiß blieb und die Deaktivierung aller Plugins (was üblicherweise bei einem weißem Dashboard empfohlen wird) nichts nützte, musste ich alle meine WordPress Ordner und Dateien bis auf die Uploads löschen und neu hochladen. Ob das jetzt alles war, weiß ich nicht.