Archiv des Autors: weed

vCenter Update 8.0.3 schlägt fehl „Pre-Install failed for vmidentity:Expand“

Veröffentlicht am von — Keine Kommentare ↓

Das Upgrade auf den neuen vCenter Server 8.0.3 („U3“) bleibt gerne mal mit diesem Fehler stehen:

Pre-install failed for vmidentity:Expand

Das Logfile in /var/log/vmware/applmgmt/Patchrunner.log verrät auch ein paar mehr Details:

vmidentity:Expand INFO vmidentity Found ssoserver cert in TRUSTED_ROOTS, This will be deleted from store
vmidentity:Expand INFO vmidentity.utils Deleting cert from TRUSTED_ROOTS VECS store
vmidentity:Expand ERROR vmidentity.utils Failed to execute command '['/usr/lib/vmware-vmafd/bin/dir-cli', 'trustedcert', 'unpublish', '--cert', '/storage/seat/software-updateub8jty50/stage/scripts/patches/payload/components-script/vmidentity/<Cert_filename.pem>', '--login', '<VC FQDN>']'
vmidentity:Expand ERROR vmidentity.utils dir-cli failed. Error 1168: Operation failed with error ERROR_NOT_FOUND (1168)

Lösung

Es gibt da noch eine Bug im Update-Setup, das das Zertifikat „ssoserver“ nicht aus dem Certificate-Store gelöscht bekommt. Aber man kann das einfach manuell machen und das Setup danach fortsetzen.

  1. Alias des „ssoserver“ Zertifikates besorgen (Die Zahlenkette hinter der Bezeichnung „Alias“)
    /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text | egrep 'Alias|ssoserver|Key Usage' -A 1 | egrep -v 'Entry type|--'
  2. Das falsche Zertifikat löschen („<ALIAS>“ durch die Zeichenkette von 1. ersetzen)
    /usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <ALIAS> -y

Danach kann man das Setup mit einem Klick auf „resume“ fortsetzen.

Excel/Word „Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen“

Veröffentlicht am von — 2 Kommentare ↓

Es kommt vor, dass Benutzer beim Öffnen von Dateien aus tief verschachtelten Ordnern (oder sehr langen Pfadnamen) diese Fehlermeldung von Office-Apps wie Excel, Word oder PowerPoint erhalten:

Die Datei kann nicht geöffnet werden, da der Dateipfad größer als 259 Zeichen. Kürzen Sie den Pfad oder den Dateinamen

Abgesehen von dem grammatikalischen Fehler, dass im ersten Satz das abschließende Verb fehlt (vermutlich „ist“), stimmt diese Meldung.

Lösung

Es gibt keine Lösung, aber einen Workaround.

Microsoft Office-Apps, allen voran Excel, unterstützen keine Pfade mit mehr als 259 Zeichen. Das hat mit der heiligen Abwärtskompatibilität zu tun, denn es könnte ja sein das noch ein Unternehmen auf VB-Macros aus den 90ern baut. Und mit „ein“ sind hier „100% der Fortune 500“ gemeint 😉

  • Windows local and UNC files: 260 characters
  • OneDrive / SharePoint files synced to the local drive: 260 characters
  • Online OneDrive / Online SharePoint files (opened directly in the WebApp) 400 characters

Der Workaround ist einfach: Die Excel-Web-App nutzen und die Datei direkt auf dem Sharepoint (Online) bearbeiten,

Debian apt-get Fehler „Die folgenden Signaturen waren ungültig: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key“

Veröffentlicht am von — Keine Kommentare ↓

Auch der Schlüssel von sury.org (oft genutztes PHP Repository) ist abgelaufen.

Die folgenden Signaturen waren ungültig: EXPKEYSIG B188E2B695BD4743 DEB.SURY.ORG Automatic Signing Key

Lösung

Das Debian-Paket-Repository sury.org hat seinen Paketsignaturschlüssel geändert. Um den Fehler zu beheben, holt man sich einfach den neuen Schlüssel mit:

apt-key adv --fetch-keys https://packages.sury.org/php/apt.gpg

Dann tut es auch sofort ein apt-get update wieder.

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

Veröffentlicht am von — Keine Kommentare ↓

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

Veröffentlicht am von — Keine Kommentare ↓

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.