Normalerweise kann man einen ESP8266 per Pin „Kurzschluss“ oder einfach über die entsprechende Taste auf dem Board Neustarten. Ich wollte das ganze aber per Code machen, und die Suche nach der Lösung hatte mich etwas verzweifeln lassen. Dabei ist es doch so einfach 🙂
esp_restart();
Ein sehr großes Mysterium beschäftigte mich auf einem meiner Macbooks, und zwar in einem einzigen Ordner. Nur im Dowloads-Ordner konnte ich Ordner nicht wie gewohnt “aufklappen”, das kleine Dreieck vor dem Ordnernamen fehlte einfach.
Nachdem ich mein Problem endlich richtig bei Google formuliert hatte, fand ich relativ schnell den entscheidenden Hinweis: Sobald man bei “Objektausrichtung” irgendwas ausgewählt hat, verschwinden die Dreiecke vor den Ordnern 🙂
Nehmen wir an, ihr richtet einen Nginx als reverse Proxy ein und möchtet nun, dass bestimmte Subdomains, die von anderen Servern durchgeschliffen werden, per Basic Auth “geschützt” werden sollen. Dann werdet ihr wahrscheinlich auf das Problem stoßen, dass ihr immer wieder nach dem Basic Auth Login gefragt werdet und der Reverse Proxy nicht korrekt agiert. Die Lösung ist ganz einfach: ihr müsst verhindern, dass die Basic Auth Header weitergereicht werden. Und das geht so:
![[Quicktip] Ordner lassen sich im MacOS Finder nicht aufklappen](https://bytelude.de/wp-content/uploads/2018/01/Bildschirmfoto-2018-01-06-um-17.05.21.png)
server {
listen 80;
server_name foo.bar.com;
access_log /var/log/nginx/foo.access.log;
location / {
proxy_set_header Authorization ""; # <== das ist die wichtige Zeile, die verhindert, dass Basic Auth weiter gereicht wird!
auth_basic "Protected";
auth_basic_user_file /etc/nginx/basic_auth;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header Host [YOUR_REMOTE_DOMAIN];
proxy_set_header Accept-Encoding "";
proxy_pass [YOUR_REMOTE_URL];
proxy_read_timeout 90;
}
}
Mittlerweile hat man mit Amazon ja einen relativ wichtigen Account, über den man nicht nur einkauft, sondern evtl. auch seine Cloud Server betreibt oder das Amazon Cloud Drive verwendet. Von daher macht die 2 Factor Authentifizierung in jedem Fall Sinn, um nicht mal eine böse Überraschung zu erleben.
Die Aktivierung ist relativ leicht: meldet euch einfach auf “amazon.com” statt auf “amazon.de” an, und geht dann in die Accounteinstellungen, wo ihr das Passwort ändern könnt (Login & Security Settings). Unter “Advanced Security Settings” könnt ihr dann 2-Factor Auth aktivieren. Sobald das erledigt ist, erscheint dieser Menüpunkt auch auf der deutschen Amazon Seite 😉
Über einen kleinen Umweg kann man auf der Bash ganz einfach alle aktuell installierten pip Pakete updaten / upgraden:
pip freeze | sed -e 's/==.*//g' > upgrade.txt pip install --upgrade -r upgrade.txt rm upgrade.txt
Das Script lässt sich alle installierten Pakete ausgeben, entfernt das “==[Versionsnummer]” hinter dem Namen und packt diese Liste in die Datei upgrade.txt. Anschließend wird diese Datei bei einem “pip upgrade” als “requirements.txt” übergeben und mit dem upgrade Befehl ausgeführt.
Da ich eben an der Provisionierung eines Macs via Ansible gespielt habe und dabei aus Versehen einen Syntax Error in der Datei /etc/sudoers drin hatte, war ich in der Falle. Ich konnte die Datei nicht mehr bearbeiten, weil ich nicht die nötigen Zugriffsrechte hatte, und sudo konnte ich auch nicht verwenden, weil ja ein Syntax Error drin war.
Die Lösung des Problems ist dann doch sehr leicht: Man öffnet den Finder, drückt “CMD + Shift + G” und trägt in das nun erscheinende Textfeld einfach “/etc” ein. Dann gelangt man in den im Finder versteckten Ordner und kann dort die Datei “sudoers” finden. Mit einem Rechtsklick auf die Datei kann man den Punkt “Informationen” aufrufen.
Dort im untersten Bereich “Freigabe & Zugriffsrechte” kann man die Dateirechte wieder korrekt setzen bzw. Schreibrechte für jedermann ermöglichen (vorher rechts unten auf das Schloss klicken und den Bereich damit entsperren). Nun kann man den/die Fehler in der sudoers korrigieren, anschließend die Schreibrechte wieder zurücksetzen und schon funktioniert sudo wieder.
Sollte euer Mac den Thunderbold-Ethernet Adapter nicht erkennen bzw. sich über “Kabel nicht angeschlossen” beschweren (selbst nach einem Neustart), dann probiert mal folgendes aus:
Systemeinstellungen -> Netzwerk und dort den Thunderbold Adapter in der linken Spalte auswählen. Anschließend den Button “weitere Optionen” auswählen und dann zum Tab “Hardware” wechseln.
Hier sollte euch die Mac Adresse des Adapters angezeigt werden. Ist dies nicht der Fall, dann ist der Adapter wahrscheinlich hinüber. Wenn die Mac Adresse angezeigt wird, dann stellt das Dropdown “Konfiguration” auf “manuell” und bei “Geschwindigkeit” auf “automatisch”.
Speichert das ganze und wartet kurz ab, dann sollte der Adapter das eingesteckte Netzwerkkabel wieder korrekt erkennen. Evtl. könnt ihr mit dem Abziehen und anschließendem erneuten Einstecken des Adapters etwas nachhelfen.
Nachdem ich mich sehr auf das neue Lightroom Update über die Creative Cloud gefreut hatte, war die Ernüchterung sehr schnell da: Die App stürzt immer kurz nach dem Start ab. Zunächst wurde mein Katalog ohne Probleme konvertiert, dann kam der Lightroom Splashscreen und kurz danach erschien der Apple Crashreport. Dieser enthielt folgende Meldung:
Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000348
Der Fehler tritt bei jedem Start von Lightroom auf. Da Adobe bisher noch keinen Fix für das Problem bereit gestellt hat, möchte ich hier zumindest einen Workaround zeigen:
Startet Lightroom mit gedrückter Alt Taste, sodass der Auswahldialog für den zu öffnenden Katalog erscheint. In diesem Dialog wählt ihr einfach euren bestehenden Katalog und klickt auf „öffnen“. Nun sollte Lightroom wie gewohnt laufen. Sollte das auch nicht funktionieren, erstellt über den Dialog einen neuen Katalog, öffnet diesen und klickt dann direkt in Lightroom auf Datei – „Katalog öffnen“ und wählt da euren „alten“ Katalog aus.
Besonders wenn man einen Jenkins Job nicht auf einen bestimmten Branch einschränkt wird man dieses Problem schnell bemerken: Jenkins baut in bestimmten Fällen auf Basis von git Branches, die eigentlich bereits gelöscht sind. Der Fehler tritt auf, weil Jenkins per default das lokale git Repository nicht mit dem Origin bezüglich gelöschter Branches synchronisiert.
Dieses Problem kann man relativ einfach beheben. Dazu geht ihr in die Konfiguration des betroffenen Jenkins Job und im Bereich “Source-Code-Management“ wählt ihr im Dropdown “Additional Behaviours“ den Punkt “Prune stale remote-tracking branches“. Damit wird vor dem Pull bzw. Fetch genau dieser Sync durchgeführt. Sprich, es werden lokal alle Branches gelöscht, die im Origin nicht mehr vorhanden sind.
In meiner Tätigkeit als Jenkins Admin hat mir das Thema „go get“ und Stash viel Kopfzerbrechen bereitet. Letztendlich ist „go get“ eine Art Alias für git pull, jedoch wird da einige Magic angewendet. Im Normalfall – also mit github und auch plain git Repos funktioniert das ganze wunderbar, sobald man aber Software wie Gitlab oder Stash verwendet, wird es etwas problematisch. Zum einen ist das „.git“, welches sowohl Gitlab als auch Stash an jedes Repo hängen ein Problem, zum anderen aber auch SSH über alternative Ports.
Zum Problem der „.git“ Endung: hängt einfach ein weiteres „.git“ an euren „go get“ Command. Also:
go get git.mydomain.com/foo/bar.git.git
Etwas kniffliger ist die Verwendung eines alternativen Ports und ssh. Stash macht nämlich genau das – der ssh Port ist 7999 in der Default Config. Aber auch hierfür gibt es eine Lösung. Dazu müsst ihr die Datei „.gitconfig“ in eurem Home Folder editieren bzw. anlegen. Die Datei muss dann so aussehen:
[url "ssh://git@stash.yourdomain.com:7999/"] insteadOf = https://stash.yourdomain.de/
Sobald ihr nun einen Checkout auf
https://stash.yourdomain.de/foo/bar.git
macht, biegt Git diesen Request auf
ssh://git@stash.yourdomain.com:7999/foo/bar.git
um. Somit könnt ihr auf andere Ports gehen, komplett auf andere Domains umschreiben usw.