Das Programm „Spotify“ kann nicht geöffnet werden

Seit dem letzten Spotify Update (Aktuelle Version: 1.0.50.41368.gbd68dbef) kann ich Spotify nicht mehr mit zwei unterschiedlichen Accounts öffnen. Die Fehlermeldung im Titel ist das Resultat. Es gibt zwei Möglichkeiten das Problem zu lösen: Spotify neu installieren unter dem aktuellen Benutzer (zum Beispiel via brew) oder die Rechte richtig setzen. Die Neuinstallation von Spotify ist nur eine temporäre Lösung. Das setzen der Rechte ist eine dauerhaftere Lösung.

Eine Gruppe, die es auf jedem Mac gibt heißt „everyone“ und jeder Account ist in dieser Gruppe. Ziel ist es Spotify von jedem Account, der in der Gruppe „everyone“ ist startbar zu machen. Das geht mit zwei Befehlen im Terminal:

:~$ sudo chown -R $USER:everyone /Applications/Spotify.app
:~$ sudo chmod -R 775 /Applications/Spotify.app

Beim ersten Befehl wird man nach seinem sudo-Passwort gefragt. Das sollte das selbe sein, das man auch zum login benutzt. Falls es nicht klappt, dann ist man kein Admin auf dem Mac. Dann hilft nur der Gang zum Admin und höfliches Bitten.

Die Befehle kurz erklärt: Mit dem chown-Befehl ändert man die User- und Gruppenzugehörigkeit des Spotify-Verzeichnisses ab. Es wird als User der aktuell eingeloggte User und als Gruppe „everyone“ gesetzt. Mit dem chmod-Befehl erteilt man nun dem User und der Gruppe Lese-, Schreib- und Ausführungsrechte. Damit können nun alle Benutzer Spotify öffnen.

Eventuell muss nach dem nächsten Update der Vorgang wiederholt werden.

 

Application „Spotify“ can’t be opened

Since the last Spotify update (Current version: 1.0.50.41368.gbd68dbef) you are not able to launch Spotify with different user accounts on your mac. The error message in the title is the result. There are two different solutions for this problem: You can reinstall Spotify every time you switch user (for example via brew) or you set the right rights in the filesystem. Reinstalling spotify every time is not the right way and can be pretty annoying. Setting the right rights is a better approach.

On every Mac there is a group called „everyone“. Every user account is in there so it would be nice when Spotify would be started if the user is in that group. You can easily achieve this with two commands in the terminal:

 

:~$ sudo chown -R $USER:everyone /Applications/Spotify.app
:~$ sudo chmod -R 775 /Applications/Spotify.app

You are asked for your sudo-password at the first command. This should be the same password as your login password. If that’s not going to work out for you then you are not an admin on that Mac. Please ask your admin for help.

The commands explained: With the chown command you change the user  and group membership of the Spotify directory in the filesystem. The currently logged in user will be set in the user part and „everyone“ as group. With the chmod-command the read, write and execute rights are changed so the current user and the group „everyone“ are allowed to do everything. Now every user can open Spotify again.

 

Maybe these steps have to be done again when the next Spotify update is released.

Insurgency Dedicated Server – crash_handler Prozess blockiert Port

Der Insurgency Dedicated Server für Linux hat seit einiger Zeit ein Stabilitäts-Problem. Wenn der Server crashed – was ja durchaus häufiger vorkommt – wird ein Crash-Dump für die Entwickler geschrieben. In diesem Fall wird der crash_handler-Prozess gestartet, der diesen dann an die Entwickler sendet. In der Prozessliste tauchen dann diese Prozesse auf:

[root@mineralwasser ~]# ps auxw | grep newworld
insurge+ 16353 100 0.0 21428 4612 pts/2 Rl+ 2016 4339:54 ./crash_handler 16350 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 31057 100 0.0 21428 4540 pts/2 Rl+ 14:59 10:39 ./crash_handler 31054 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 32614 100 0.0 21428 4776 pts/2 Rl+ 2016 3838:20 ./crash_handler 32611 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1

Es ist zwar cool, dass es so etwas gibt, jedoch hat dieser Prozess drei große Probleme. Der Prozess

  1. läuft endlos
  2. belegt permanent einen CPU Kern zu 100%
  3. verhindert das der Port des Gameservers freigegeben wird. Wenn der Server dann neu starten will, dann kann er auf diesen nicht binden. Daraufhin wird so lange hochgezählt, bis ein freier Port gefunden wurde. Das Resultat für die Spieler: Der Server verschwindet aus der Favoritenleiste, da der Server auf Port 27016 und nicht auf 27015 läuft.

Ich habe dazu ein Ticket bei New World Interactive eröffnet. Dort wurde mir sehr schnell gesagt, dass das Problem bekannt ist. Nun ja ich warte nun schon etwas länger darauf, deswegen habe ich einen Workaround gefunden. In die Crontab des UNIX-Gameserveraccounts einfach folgenden Eintrag hinzufügen:

# Kill the insurgency crash_handler process
*/1 * * * * /usr/bin/pkill crash_handler

Das funktioniert, da der Server dem crash_handler Prozess ein bisschen Zeit gibt, bevor der Server neustartet. Gerade genug, damit der Cronjob aktiv werden kann.

Insurgency Dedicated Server – crash_handler process blocks port

The insurgency dedicated server for linux currently has some problemes with its stability. If the server crashes – which happens quite often – a crash dump file is written and sent to the developers for further review. There’s a special binary named crash_handler which sends the dump file. When starte the process list looks like this:

 

[root@mineralwasser ~]# ps auxw | grep newworld
insurge+ 16353 100 0.0 21428 4612 pts/2 Rl+ 2016 4339:54 ./crash_handler 16350 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 31057 100 0.0 21428 4540 pts/2 Rl+ 14:59 10:39 ./crash_handler 31054 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1
insurge+ 32614 100 0.0 21428 4776 pts/2 Rl+ 2016 3838:20 ./crash_handler 32611 http://crash.newworldinteractive.com/api/dumps/submit/insurgency 1 22907 -1

It’s okay that such a mechanism exists if it wouldn’t have three problems. The process:

  1. never finishes
  2. blocks 100% of a CPU core
  3. prevents the release of the gameserver port. For me that’s the main problem. If the new server is started after a crash the port is still blocked. The gameserver then seeks for the next free port. It won’t show up in you favourite list anymore because it binds then for example on port 27016 and not on 27015.

I’ve opened a ticket at New World Interactive. They told me pretty quick that the problem is known. For now I’m already waiting a bit long for a fix. I’ve found a workaround. Place the following command snippet in the gameservers‘ UNIX user:

# Kill the insurgency crash_handler process
*/1 * * * * /usr/bin/pkill crash_handler

This will kill the crash_handler-process every minute. The gameserver gladly gives the crash_handler-process enough time bevore the server finally restarts. Just enough that the cronjob can kick in and force the „release“ of the port.

UniFi: Access Point schaltet Radio ab ohne Controller

Beim Updaten des Betriebssystems auf dem mein Unifi Controller läuft hatte ich vor kurzem ein sehr ärgerliches Problem: Als der Controller abgeschaltet war hat der Access Point nach ca. drei Minuten aufgehört das WLAN auszustrahlen. Das ist Blöd, wenn der Laptop in dem weggebrochenen WLAN hängt.

Nur weil der Controller nicht erreichbar ist sollte der Access Point aber nicht aufhören das WLAN auszustrahlen. Dieses Verhalten kann man auch einstellen. Die Entsprechende Einstellung befindet sich in den Site-Setting und heißt „Enable connectivity monitoring and wireless uplink“:

 

Source: https://community.ubnt.com/t5/UniFi-Wireless/What-does-Uplink-Connectivity-monitor-do/td-p/1561335

UniFi Controller: TLS Zertifikat tauschen

Ich habe sehr lange die D-Link DAP-1665 für mein WLAN an meinen Wohnorten benutzt. Leider bin ich vom Handling und von der Performance her nicht wirklich überzeugt gewesen und habe deswegen auf Access Points von Ubiquity Networks geupgraded. Genauer gesagt auf die UniFi AP AC Lite.
Hersteller: https://www.ubnt.com/unifi/unifi-ap-ac-lite/
Amazon: http://amzn.to/2hMw3Fi

Die Besonderheit bei diesen Geräten ist, dass die Access Points von einem Controller gesteuert werden. Die WLAN Einstellungen und viele weitere Optionen werden zentral über dieses Managment Tool gesteuert. Im professionellem Umfeld  ist ein arbeiten ohne Controller überhaupt nicht denkbar. Im privatem Umfeld sind solche Systeme nicht üblich, da sie normalerweise sehr teuer und umständlich sind. Ubiquity hat mit seinen 100 € Access Points und kostenloser Controller Software aber ein tolles Produkt für dein Heimanwender geschaffen. Ein ganzes Haus zum Beispiel mit 4-8 Access Points effizient abzudecken sind somit kein Problem mehr.

Die Controller Software ist in Java implementiert und hat als Benutzerschnittstelle eine Weboberfläche. Diese ist standardmäßig mit TLS abgesichert, jedoch muss dazu ein valides Zertifikat erstellt werden, damit der Browser nicht permanent vor einer unsicheren Verbindung warnt.
Um die Weboberfläche mit einem eigenen SSL/TLS Zertifikat auszustatten, muss man ein bisschen basteln, da diese keine Möglichkeit zum Austausch bietet. Read More „UniFi Controller: TLS Zertifikat tauschen“

postfix „cannot find your hostname“ und „transport smtp failure“

Ich habe meinen Root-Server umgezogen von Debian 8 auf Arch Linux. Bei postfix (aktuell in der Version 3.1.3 hatte ich zwei Phänomene.

Reverse Lookup schlägt fehl mit „cannot find your hostname“

Unschöne Logmeldungen tauchten auf:

Dez 20 22:35:04 mineralwasser postfix/smtpd[31080]: Anonymous TLS connection established from unknown[2607:f8b0:4001:c06::245]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Dez 20 22:35:04 mineralwasser postfix/smtpd[31080]: NOQUEUE: reject: RCPT from unknown[2607:f8b0:4001:c06::245]: 450 4.7.25 Client host rejected: cannot find your hostname, [2607:f8b0:4001:c06::245]; from=<3HENWWAcLBcMwx0nyu77x323kn.lxvqnuux4nuxlA27.mn@youtube-subscriptio
Dez 20 22:35:05 mineralwasser postfix/smtpd[31080]: disconnect from unknown[2607:f8b0:4001:c06::245] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7

Mein Postfix ist so konfiguriert, dass der Reverse DNS Eintrag zum angegebenen HELO Hostname passen muss. Ist das nicht der Fall, dann wir die E-Mail nicht angenommen. Diese Maßnahme filtert viele spamversendende E-Mail Server weg. Diese Regel wollte ich also nur ungern deaktivieren.
Eine manuelle Rückwärtsauflösung funktioniert jedoch einwandfrei. Es handelt sich also nicht um ein DNS Problem. Als nächstes hatte ich systemd-resolved in Verdacht. Da dieser Service aber nicht aktiviert ist musste es doch an postfix liegen.
Den entscheidenden Hinweis gab folgende Logmeldung:

/etc/postfix/master.cf: line 47: using backwards-compatible default setting chroot=y

Read More „postfix „cannot find your hostname“ und „transport smtp failure““

Install Icinga 2 on pfSense 2.3

pfSense 2.3 is using FreeBSD 10.3 as base. Needless to say that my firewall has to be in my monitoring. The install procedure isn’t as easy as expected.
pfSense 2.3 is since this version fully using the pkg infrastucture which should be well known by the BSD users. But it doesn’t provide a „pkg –install-dependencies“ command :-( You have to resolve them by hand. The needed links are:

http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/mysql56-client-5.6.30.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icu-55.1,1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/boost-libs-1.55.0_12.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/yajl-2.1.0.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/postgresql93-client-9.3.13_2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/monitoring-plugins-2.1.2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icinga2-2.4.10.txz

Each link have to be used with „pkg install <url>“. For example:

:-$ pkg install http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz

After all these steps you can normally work with Icinga 2. The config files are not stored the Linux way unter /etc/icinga2 but under /usr/local/etc/icinga2.

Icinga 2 auf pfSense 2.3 installieren

pfSense 2.3 benutzt als Basis FreeBSD 10.3. Und auch meine Firewall muss ins Monitoring. Leider war das etwas schwieriger als gedacht.
pfSense 2.3 benutz seit dieser Version vollständig die pkg Infrastruktur, die BSDler gewohnt sind. Leider gibt es kein „pkg –install-dependencies“ Kommando. Abhängigkeiten müssen selbst installiert werden :-(

Damit pfSense trotzdem aus den Repos (auf BSD nennt man die Ports) installiert werden, muss man selber Hand anlegen.

http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/mysql56-client-5.6.30.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icu-55.1,1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/boost-libs-1.55.0_12.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/yajl-2.1.0.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/postgresql93-client-9.3.13_2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/monitoring-plugins-2.1.2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icinga2-2.4.10.txz

Diese Links führt man nun nacheinander auf der Konsole un dem Prefix „pkg install <url>“ aus. Also zum Beispiel:

:-$ pkg install http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz

Danach kann man ganz normal mit Icinga 2 arbeiten. Die Konfig Dateien liegen aber nicht (wie auf Linux gewohnt) unter /etc/icinga2 , sondern unter /usr/local/etc/icinga2.