Damit ich zu meinen reparierten Xbox 360 auch passende Controller habe, habe ich einige Defekte von Ebay gekauft.
In diesem Video zeige ich, wie ich aus zwei defekten Controllern einen Funktionierenden zusammenbaue.
In letzter Zeit habe ich einige defekte Xbox 360 gekauft. Viele davon hatten das Problem, dass sich die Lade / das Laufwerk einfach nicht öffnet. Bei manchen ging es sporadisch, bei anderen ging es überhaupt nicht.
Ein typisches Zeichen für das Problem ist, dass das Laufwerk Geräusche von sich gibt und grün blinkt, sonst aber nichts Weiteres passiert.
In dem folgenden Video zeige ich, wie man das Problem behebt:
Für alle, die den Lösungsweg gerne in Textform sehen möchten, habe ich meinen Weg hier auch aufgeschrieben:
Hoffentlich kann jemand mit dieser Anleitung auch seine Xboxen reparieren. Bei Fragen freue ich mich auf Kommentare unter diesem Blog Post oder unter dem YouTube-Video.
Wer unter Windows ein Start-Skript einrichtet, kann Aufgaben wie das Pullen von Git-Repositorys und das Starten von Programmen schön automatisieren.
Aufgaben kann man mit der Windows Aufgabenplanung planen. Diese wird über Start -> Suche nach „Aufgabenplanung“ auch schnell gefunden.
Eine neue Aufgabe kann über „Einfache Aufgabe erstellen …“ ganz einfach angelegt werden.
Zur besseren Übersicht sollte man der neuen Aufgabe natürlich einen Namen geben. „Startup“ wäre eine Option …
Anschließend gibt es verschiedene Optionen, wann die Aufgabe ausgeführt werden soll. „Beim Anmelden“ führt die Aufgabe nach der Anmeldung eines Benutzers aus.
Natürlich muss man angeben, was genau durchgeführt werden soll. „Programm starten“ ist hier allerdings die einzige Möglichkeit, welche nicht veraltet ist.
Da ich ein Batch-Skript geschrieben habe (eine Anleitung, wie man ein Batch-Skript schreibt, kann man mit einer gezielten Suche schnell finden), wähle ich dieses natürlich aus.
Kurz vor dem Ende können wir unsere Auswahl noch einmal begutachten.
Fertig. Die Aufgabe wurde erstellt und sollte bei allen zukünftigen Anmeldungen ausgeführt werden können.
Ich habe mich lange nur über Benutzername und Kennwort auf meinen Servern eingeloggt. Das kann man mit einem Key allerdings viel bequemer durchführen. Wie das genau geht, zeige ich in diesem Artikel.
Als Voraussetzung nehme ich ein Linux-System sowohl für Client als auch für den Server als gegeben an. Unter Windows sind die Schritte evtl. etwas anders.
Erstellen wir uns nun zuerst auf unserem Client einen Key. Hierzu wechseln wir ins passende Verzeichnis:
cd ~/.ssh
Das Generieren erfolgt einfach mit dem folgenden Befehl:
ssh-keygen
Die Fragen können wir alle einfach leer lassen. Danach verbinden wir uns auf unserem Server und legen im Home-Verzeichnis des gewünschten Nutzers die folgende Datei an:
nano ~/.ssh/authorized_keys
Wenn wir gleich schon nano geöffnet haben, können wir auch gleich den Inhalt aus der lokal generierten id_rsa.pub Datei (dem Key) hineinkopieren.
Voila. Das Login ohne Benutzername und Passwort sollte nun klappen.
Ein Start-Skript nach dem Anmelden eines Benutzers kann bestimmte Aufgaben wie z.B.: das Pullen von einem Git Repository oder das Öffnen von Anwendungen gleich beim Start ausführen.
Da ich mir unter Xfce ein solches Skript eingerichtet habe, möchte ich nun zeigen, wie das funktioniert. Als Beispielsystem werde ich Xfce unter Manjaro Linux verwenden.
Zuerst sollte man natürlich sein Skript (z.B.: als Bash-Skript) schreiben. Hierauf gehe ich allerdings in diesem Artikel nicht genauer ein. Seiten wie „ubuntuusers“ bieten dazu genügend gute Anleitungen.
Anschließend kann man über die Xfce-Einstellungen den Punkt „Sitzung- und Startverhalten“ auswählen.
Über „Automatisch gestartete Anwendungen“ kann man mit dem Button „Hinzufügen“ auch eine neue Startanwendung in die Liste aufnehmen.
Das anschließende Fenster möchte mit einem verständlichen Namen und dem Pfad zu unserem Skript gefüllt werden.
Nun sollte das Skript immer nach der Anmeldung automatisch ausgeführt werden.
Ich wollte heute unter Manjaro Linux meine Bildschirmhelligkeit anpassen. Leider gibt es direkt von Manjaro / Arch Linux hier keine GUI-Einstellung zum Regeln der Helligkeit.
Was es aber gibt, sind zwei nützliche Pakete: light und Clight. Mit light kann man die Helligkeit über die Konsole anpassen, Clight erkennt die aktuelle Umgebungshelligkeit über die Webcam und passt dementsprechend die Bildschirmhelligkeit an.
Da Clight aber nur über Arch AUR erhältlich ist, habe ich mal light ausprobiert und bin damit zufrieden.
Light kann man ganz einfach über pacman installieren:
pacman -S lightAnschließend kann man die aktuelle Helligkeit als Prozentwert ausgeben lassen:
$ light -G
23.99
Und die Helligkeit um x Prozent erhöhen:
$ light -A 70Bereits im Januar dieses Jahres habe ich über meine Erfahrungen mit Gitea Updates berichtet. Das große Problem von Gitea ist, dass es sich nicht automatisch selbst aktualisiert. Ein Issue für das Problem ist schon seit fast 2 Jahren offen: https://github.com/go-gitea/gitea/issues/518#issuecomment-441742904
Ich hasse es wirklich, wenn sich eine sicherheitskritische Webanwendung nicht von selbst aktualisiert – das erlaubt Hackern ein leichtes Spiel. Vor vier Monaten habe ich nun schon die Entwicklung eines automatischen Gitea Update Skripts begonnen, welches ich nun vorstellen möchte.
Wie ich bereits erwähnt habe, bin ich kein Fan von manuellen Updates und schreibe deshalb für viele meiner Systeme Skripts zum automatischen Aktualisieren. Diese Programme sind schnell erstellt worden und auf meine Bedürfnisse angepasst und können unsauberen Code enthalten. Ich bin allerdings für Verbesserungsvorschläge in Form von Issues und Pull-Requests offen!
Manche Entwickler – wie der Ersteller von Kanboard – haben eine grundsätzliche Skepsis gegenüber automatischen Updates. Es gibt hierfür gute Gründe – du möchtest ja sicher nicht, dass deine Anwendung plötzlich aufgrund eines fehlerhaften Upgrades nicht mehr geht – deshalb empfehle ich automatische Upgrades nur, wenn auch automatische Backups eingerichtet sind.
Die veröffentliche Version meines Skripts kann auf GitHub gefunden werden: https://github.com/CMiksche/gitea-auto-update
Ich habe das Skript nur für mein Debian System entwickelt und getestet. Wenn das Skript einfach so auf Windows, MacOS oder Linux Systemen ohne Systemd ausgeführt wird, können Fehler nicht vermieden werden! Für diese Systeme muss das Skript definitv angepasst werden.
Wenn das Design von Gitea angepasst wurde, kann es sein, dass ein automatisches Upgrade dieses Template zerstört. Hierauf wird im Skript nicht geprüft.
Bitte zuerst die oberen Absätze lesen, ohne Beachtung dieser Hinweise kann es schnell in die Hose gehen!
Die Anwendung ist recht einfach:
pip install gitea-auto-update
[Gitea]
site=https://your-gitea-instance.com/api/v1/version
apiUrl=https://api.github.com/repos/go-gitea/gitea/releases/latest
system=linux-amd64
file=/usr/local/bin/gitea
tmpDir=/tmp/
buildFromSource=None
sourceDir=/home/git/go/src/code.gitea.io/gitea
logFile=update.loggite-auto-update --settings=/path/to/settings.ini aus, um das erste Upgrade zu testen/etc/crontab Datei und rufe dort einen Aufruf des Skripts ausSo einfach geht das. Wenn du auf Probleme stößt, zögere nicht einen Issue oder Pull-Request auf Github zu erstellen oder hier einen Kommentar zu hinterlassen.
Diesen Beitrag habe ich auch auf Englisch veröffentlicht.
Ich habe nun alle meine Debian Systeme auf die neueste Version „Stretch“ ohne größere Probleme aktualisieren können.
Da ich in den letzten Jahren allerdings immer größere Probleme hatte und weiß, dass eine gute Anleitung hilfreich sein kann, möchte ich hier meine Vorgehensweise anhand eines Webservers mit Debian 8 beschreiben.
Gerade bei Webservern ist eine Aktualisierung wichtig, da Sicherheitslücken den Server schnell zu einer Virenschleuder verwandeln können.
Sollte PHP auf dem Webserver verwendet werden, führt kaum ein Weg an einem Upgrade vorbei, da Debian 8 keine aktuelle PHP-Version ausliefert. (Debian 9 zwar auch nicht wirklich aber dazu später mehr …)
Folgende Punkte führe ich immer vor einer Webserver-Aktualisierung durch:
Mit
apt update
und danach
apt upgrade
aktualisiert man die aktuellen Pakete.
Damit man bei Problemen schnell wieder auf Debian Jessie wechseln kann, ist eine Sicherung der alten Sources List hilfreich:
cp /etc/apt/sources.list /etc/apt/sources.list_backup
Wichtig: Sollte es auch Dateien unter /etc/apt/sources.list.d geben, ist auch eine Sicherung dieser Dateien nicht überflüssig!
Nun sollte man den Namen der alten Version durch den Namen der neuen Version in der Sources.list und allen anderen Dateien unter z.B.: /etc/apt/sources.list.d aktualisieren. sed ist für solche Aufgaben perfekt geeignet:
sed -i 's/jessie/stretch/g' /etc/apt/sources.list
Nachdem wir nun die Quellen auf die neue Version geändert haben, können wir die Paketquellen mit den folgenden Befehl aktualisieren:
apt update
Anschließend aktualisieren wir die Pakete wieder mit:
apt upgrade
Hier kann es sein, dass wir den Befehl mehrmals ausführen müssen und gefragt werden, ob wir die aktuellen Konfigurationsdateien behalten wollen oder neue Konfigurationsdateien übernehmen (letzteres sollte nur gemacht werden, wenn nichts an den Konfigurationen geändert wurde).
Mit den bisherigen Befehlen wurden noch nicht alle Pakete aktualisiert. Um das Systemupgrade abzuschließen, benötigen wir eine Ausführung des folgenden CLI-Befehls:
apt dist-upgrade
Nach einem großen Upgrade empfiehlt sich ein Neustart, welcher mit
reboot
durchgeführt werden kann.
Um festzustellen, ob wir die gewünschte Version haben, kann man diese mit cat ausgeben lassen:
cat /etc/issue
Zum Zeitpunkt dieses Posts gibt es noch keinen mir bekannten Weg, um PHP direkt von den Debian Sources zu beziehen. Deshalb müssen für PHP 7.2 Fremdquellen genutzt werden. Bei Fremdquellen sollte immer auch auf das Sicherheitsrisiko geschaut werden.
Vorerst sollten wir PHP deinstallieren:
apt purge php*
Anschließend den Schlüssel des fremden Repos importieren:
wget -qO - https://packages.sury.org/php/apt.gpg | sudo apt-key add -
Um dann die Quelle in eine Sources List zu speichern:
sudo echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list
Die Paketquellen aktualisieren wir wieder mit:
apt update
Nun können wir endlich die neue Version von PHP installieren:
sudo apt install php7.2
(hier können natürlich auch noch weitere Pakete wie php7.2-imap gewählt werden)
Da ich gerne nginx als Webserver verwende, musste ich für die neue PHP-Version auch den Socket in den sites-available aktualisieren.
Dafür wechseln wir erst in das Verzeichnis der virtual Hosts:
cd /etc/nginx/sites-available/
Danach bearbeiten wir die gewünschte Website mit einem Editor unserer Wahl – z.B.: nano.
Wir suchen erst nach fastcgi_pass und passen die Zeile dann wie folgt an:
fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;
Um die Änderung aktiv zu schalten, müssen wir den Webserver noch neu starten:
systemctl restart nginx.service
Ich hoffe, meine Erklärung des Debian Upgrades war hilfreich. Wenn ihr zukünftig Tutorials zu Themen wie Debian Webserver erhalten möchtet, könnt ihr mir gerne auf Twitter folgen.
Beim Einloggen in einen WordPress Blog hatte ich vor Kurzem nach einem Upgrade von Debian und PHP einen 502 Bad Gateway Error. Dieser wurde von einem „upstream sent too big header“ Fehler ausgelöst.
Da ich zu diesem Fehler nur englische Beiträge gefunden habe, möchte ich hier mal einen Lösungsweg auf Deutsch teilen.
In der nginx Error Log, welche man unter Debian unter /var/log/nginx/error.log finden kann, fand ich die folgende Zeile:
[error] upstream sent too big header while reading response header from upstream, client: ***.***.***.***, server: *****.***, request: "GET /wp-login.php
(Domain und IP-Adresse aus Datenschutzgründen unkenntlich gemacht)
Eine Lösung, um diesen Fehler zu beheben, ist unter Debian die /etc/nginx/fastcgi.conf zu bearbeiten und die folgenden Zeilen hinzuzufügen, um die Buffer Size festzulegen:
fastcgi_buffers 16 16k; fastcgi_buffer_size 32k;
Natürlich muss man selbst ermitteln bzw. wissen, welche Buffergrößen notwendig sind. Nginx selbst hat hierzu auch eine gute Dokumentation online: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffer_size
Nachfolgend zeige ich, wie man einen Twitch Livestream aufnehmen kann. Die Funktionsweise funktioniert aber auch bei Konkurrenten wie YouTube Live und anderen Streaming-Anbietern ganz einfach.
Bevor wir mit dem Streamen anfangen können, benötigen wir zwei Programme:
Den VLC Media Player kann man auf fast allen Betriebssystemen wie gewohnt installieren, für Streamlink empfiehlt sich eine Installation über die Paketverwaltung pip von Python im jeweiligen Terminal oder der Kommandozeile des Betriebssystems:
(sudo) pip install streamlink
Wem das zu kompliziert ist, kann auch eine ausführbare Datei von Streamlink herunterladen und so das Programm auch wie gewohnt unter z.B.: Windows installieren: https://github.com/streamlink/streamlink/releases
Mit den folgenden Befehl kann der Stream in VLC geöffnet werden (nachfolgend am Beispiel des Twitch Presents Streams von Twitch):
streamlink https://www.twitch.tv/twitchpresents bestDas „best“ steht hierbei für die Qualität des Streams. Es gibt hier natürlich auch noch weitere Optionen, die der Dokumentation von Streamlink entnommen werden können.
Nun einfach in VLC unter dem Menüpunkt „Wiedergabe“ den Punkt „Aufnehmen“ anhaken. VLC speichert anschließend automatisch die Wiedergabe in Video-Dateien – unter macOS werden die Streams standardmäßig als .ts-Dateien im Download-Ordner gespeichert.
Ich hoffe, ich konnte verständlich erklären, wie man einen Twitch Livestream aufnehmen kann. Falls noch Fragen dazu offen sind, kann gerne ein Kommentar hinterlassen werden.