Debian apt-get Fehler „Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY B7B3B788A8D3785C“

Hat man das MySQL Repository zu seiner /etc/apt/sources.list hinzugefügt, tritt nach einer Weile bei einem apt-get update der Fehler auf:

Fehler:1 http://repo.mysql.com/apt/debian bullseye InRelease
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY B7B3B788A8D3785C

Lösung

Die fehlenden GPG-Keys müssen nur schnell hinzugefügt werden:

sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys B7B3B788A8D3785C

Der strenge Syntax mit den Protokoll-Header („hkp://“) und dem Port (:80) ist dabei erst seit Bullseye (11) Pflicht.

So erstellt man aus einem MP3 einen Spotify Song (WAV 16Bit, 44.1kHz, 1411kbps) mit ffmpeg

Ein interessanter Fall dieser Woche. Jemand hat einen Song gemacht, der bei Spotify veröffentlich werden soll. Das Master davon liegt aber nur als MP3 vor.

So konvertiert man MP3 zu WAV für Spotify

Spotify benötigt für eine Veröffentlichung ein „Master“ File mit sehr spezifischen Format-Daten:

  • Sampel-Size: 16bit (Sample size)
    Die „sample size“ bestimmt den maximalen Dynamikbereich eines digitalisierten Tons; umfasst also die ‚Größe der Zahl‘ des Verhältnisses zwischen der höchsten und niedrigsten Amplitude. Ist praktisch das bestimmende Qualitätsmerkmal bei PCM (WAV-Dateien).
  • Sample Rate: 44.1kHz (Abtastrate)
    Die „Abtastrate“ ist die Frequenz, in der die „Höhe der Welle“ eines Tons pro Sekunde gemessen wird. Also wie oft die Musik „abgetastet“ wird. Höhere Frequenz = mehr Messwerte = größere Datei.
  • 1411kbps (bit rate)
    Die Bitrate oder auch „Sample Rate“ ist die Datenmenge pro Sekunde, bestimmt also letztendlich die Dateigröße. Bei MP3 kann diese innerhalb einer Datei variieren (variable Bitrate), bei WAVs gibt es meist einen statischen Wert. Bestimmt indirekt die Qualität, denn wen man weniger Bits für Informationen hat, muss man ja etwas weglassen.

Diese drei Werte hängen, was die Qulität angeht, natürlich letztendlich zusammen. Es gilt die einfache Formel: bit rate = sample rate x bit depth. Konsequenterweise folgt daraus auch: bit rate x dauer = file size.

Die von Spotify angegebenen Werte entsprechen einem heute üblichen digitalen Master in sehr guter Qualität. Ein MP3 ist (in der Regel) bereits mit Verlusten komprimiert, enthält also nicht mehr alle Informationen des Originals. In diesem Fall musste aber aus dem „eigentlich“ schlechteren MP3 das „gute“ Master zurückgerechnet werden. Technisch ist das kein Problem, aber der die „fehlenden“ Informationen, die beim Erstellen des MP3 entfernt wurden, kommen natürlich nicht zurück.

Lösung

Mit dem Universalwerkzeug ffmpeg ist das problemlos möglich:

ffmpeg -i '<INPUT>.mp3' -ar 44100 -sample_fmt s16 -minrate 1411k <OUTPUT>.wav

In seine Bestandteile zerlegt:

  • „-ar 44100“ aus -ar[:stream_specifier] freq (input/output,per-stream)
    Setzt die Audio-Abtastfrequenz des Codec. Für Ausgabestreams wird sie standardmäßig auf die Frequenz des entsprechenden Eingabestreams eingestellt, hier wollen wir 44,1khz erzwingen.
  • „-sample_fmt s16“ aus -sample_fmt[:stream_specifier] sample_fmt (output,per-stream)
    Legt das Audio-Sample-Format fest, hier 16bit. Eine Liste der Möglichkeiten bekommt man mit -sample_fmts
  • -minrate 1411k aus -minrate [min/max]
    Die minimale Bitratentoleranz (in Bits/s mit Multiplikator), hier statisch bei 141,1kbps.

vSphere CD ISO einlegen „Der Steuerungsvorgang für die Verbindung ist für die Festplatte „sata0:0“ fehlgeschlagen.“

Beim Versuch, eine auf einem Datastore gespeicherte ISO-Datei anzuhängen, schlägt der Vorgang mit dem folgenden Fehler fehl:

Der Steuerungsvorgang für die Verbindung ist für die Festplatte „sata0:0“ fehlgeschlagen.

Lösung

Das Problem ist zum Glück schnell gelöst:

  • VM abschalten, an die die ISO angehängt werden soll. Die Anpassung ist (leider) nicht im laufenden Betrieb möglich.
  • vSphere Client öffnen > VM bearbeiten
  • Das CD-Laufwerk aufklappen
  • Den Gerätemodus auf „Passthrough-CD-ROM“ umstellen
  • VM wieder starten

Jetzt kann man auch wieder fehlerfrei ISOs einlegen.

Wir haben auch schon VMs gesehen, wo das CD-Laufwerk nicht änderbar war (ausgegraut). In solchen Fällen haben wir das Laufwerk einfach entfernt und ein neues wieder hinzugefügt …

Microsoft 365 Exchange online Mailbox neu mit einem lokalen Benutzer verbinden

Es kommt in Hybrid-Szenarien schon mal vor, dass ein Admin einen synchronisierten AD-Benutzer nachträglich innerhalb von Microsoft 365 mit einem Postfach versieht. Das ist nicht „supported“, das Postfach taucht nicht im Exchange ECP auf und es drohen fiese Konflikte, wenn Attribute synchronisiert werden. Außerdem kann es auf einmal doppelte Mailadressen geben, weil beide Exchange-Server auf unterschiedliche Adresslisten zugreifen.

Da sollen/müssen die Benutzer wieder auftauchen.

Lösung

Eine „offizielle“ Lösung gibt es nicht so richtig. Exchange Online verwaltet Postfächer etwas anders als der „on Premises“ Exchange, man kann daher Postfächer eigentlich nicht auf die Schnelle ab- und wieder anhängen. Vor allem nicht mit verbundenen Benutzern (Outlook oder Applegeräte).

Es gibt aber einen (bisher) ganz brauchbar funktionierenden Trick.

  • Wenn eine Mailbox in EXO angelegt wurde
  • UND diese On-Premises im ECP [noch] nicht existiert (Postfachtyp „Office 365“)
  • DANN kann man die Mailbox „noch einmal“ On-Premises als Remote-Mailbox enablen. ACHTUNG: Dabei werden die im Exchange Online erstellten Attribute (SMTP-Adressen, Kontaktinformationen, Berechtigungen …) bei der nächsten Synchronisation überschrieben.

Schritt für Schritt geht das so

  1. Exchange GUID der Mailbox aus Exchange Online holen:
    Get-Mailbox <NAME> | fl ExchangeGuid
  2. Primäre E-Mail-Adresse der Mailbox auslesen (wenn nötig):
    Get-Recipient <NAME>| fl PrimarySmtpAddres
  3. Alle weiteren E-Mail-Adressen der Mailbox auslesen (wenn nötig):
    Get-Recipient <NAME> -ResultSize Unlimited | fl @{Name="EmailAddresses";Expression={($_.EmailAddresses | Where-Object {$_ -clike "smtp*"} | ForEach-Object {$_ -replace "smtp:",""}) -join ", "}}
  4. Mailbox On-Premises „neu“ in Exchange Online enabeln
    Connect-ExchangeOnline
    Enable-RemoteMailbox <NAME> -RemoteRoutingAddress @domain.mail.onmicrosoft.com

    Set-RemoteMailbox <NAME> -ExchangeGuid <GUID AUS SCHRITT1>
  5. Im ECP (On-Premises) die E-Mail Adressen aus Schritt 2 und 3 der Mailbox wieder hinzufügen und einen „Entra ID Connect“ Sync („initial“) starten.

Wenn das erledigt ist, kann es eine Weile dauern, bis das Online-Adressbuch das Postfach wieder korrekt anzeigt. In meinem letzten Fall hier etwas weniger als 24 Stunden.

Windows Server 2019/2022 RRAS (VPN) Fehler „8007042a“

Microsoft hat mit einem der Updates aus 2023 eine mehr oder weniger folgenschwere Änderung eingeführt. Auf die Änderung an der Protokollierungsschnittstelle geht dieser Artikel nicht ein – aber auf die Folge.

Nach einem Reboot eines RRAS Servers funktioniert die VPN-Einwahl plötzlich nicht mehr. Auf dem Server ist der „Routing und RAS“ Dienst seltsamerweise nicht mehr gestartet und lässt sich auch nicht mehr starten. Das Ereignisprotokoll sowie die Fehlermeldung beim manuell Start zeigen den Fehler 8007042a an.

Lösung

Es liegt an der Startreihenfolge. Zuerst muss der RRAS-Dienst gestartet sein, dann darf der NPS (Netzwerkrichtlinienserver) folgen.

Quick-Fix: Beide Dienste beenden, Routing und RAS starten, dann NPS:

sc stop rasman
sc stop IAS
sc start rasman
timeout /t 3
sc start IAS

Eine dauerhafte Lösung, die auch beim nächsten Reboot funktioniert, ist die Abhängigkeit des NPS vom RRAS hinzuzufügen:

sc config IAS depend= RpcSS/RemoteAccess 

Dann klappt’s auch mit dem nächsten Neustart.

Vielleicht hätte Nadella bei Microsoft die QS-Abteilung für Updates doch nicht komplett hinauswerfen sollen …