airpods am huawei p20pro
da ich diese in-ear kopfhoerer mit gummidichtung nicht leiden kann, musste was anderes her. die auswahl ist dann schon nicht mehr so gross. und da ich zu faul war, mich gross mit zu beschaeftigen, hab ich einfach mal die apple airpods genommen. schoen mitm android gekoppelt.. funktioniert wunderbar. ok, der funktionsumfang zur bedienung beschraenkt sich dann auf die pause funktion bei doppeltem tippen auf einen der ohrhoerer. siri und der ganze google assistant furz kram – geschenkt.
was soll ich sagen.. klanglich so naja. weniger, als ich fuer das geld erwarten wuerde. aber welten besser als das, was man in guenstigen, einzelnen bluetooth kopfhoerern bekommt. und ich war erstaunt, wie verdammt laut die dinger gehen!
tja.. bis ich dann auf die idee kam mal zu schauen, obs nicht ein firmware update fuer die teile gibt. dazu muss man sie selbverstaendlich mit einem ios geraet koppeln. also das ipad entstaubt und gecheckt… .leider kein firmware update verfuegbar. nachdem ich die wieder ans android gekoppelt habe, war ich ueberrascht. der doppeltipp auf die kopfhoerer hat nun die skip funktion inne… wurscht, kann ich mit leben. aber viel schlimmer war, dass die auf einmal nicht mehr richtig laut gingen. sondern nur noch so halb laut, was nicht mal reicht, um vorbeifahrende autos wirkungsvoll zu uebertoenen. kurzerhand habe ich dann einen reset auf werkseinstellungen gemacht. die funktion des doppeltipps war wieder wie vorher… nur laut gingen sie leider nicht mehr.
ich war schon kurz davor, die teile als defekt zurueck zu schicken. aber dann habe ich doch nochmal google angeworfen. wie immer viel scheissdreck und hokuspokus gefunden, aber ein ergebis hat mich auf den richtigen weg gebracht. in den developer optionen des androiden kann man irgendwas mit bluetooth und lautstaerke drehen. leider habe ich das bei meinem huawei nicht gefunden, sondern nur die einstellung “bluetooth absolute volume” mit der beschreibung “auto-sync bluetooth device and phone volume when connected over bluetooth”. und jipppiiiiieee….. nach einem reconnect per bluetooth gingen sie wieder laut! was ein glueck.
fritzbox reboot mit cronjob
seit super vectoring spinnt meine fritzbox 7590 alle paar wochen mal rum. dann hat das entertain tv aussetzer und laeuter so spaesschen. also ein kleines scriptchen auf einen der linux server drauf, welches die fritzbox regelmaessig neu starten soll. auf der fritzbox extra einen user “reboot” dafuer angelegt und ihm die Berechtigung “FRITZ!Box Einstellungen” gegeben, den port 49000 zur fritzbox in der firewall freigeschaltet und einen woechentlichen cronjob dafuer angelegt. und hier das script:
#!/bin/bash IP="10.10.10.1" FRITZUSER="reboot" FRITZPW="strongpassword" location="/upnp/control/deviceconfig" uri="urn:dslforum-org:service:DeviceConfig:1" action='Reboot' curl -k -m 5 --anyauth -u "$FRITZUSER:$FRITZPW" http://$IP:49000$location -H 'Content-Type: text/xml; charset="utf-8"' -H "SoapAction:$uri#$action" -d "<?xml version='1.0' encoding='utf-8'?><s:Envelope s:encodingStyle='http://schemas.xmlsoap.org/soap/encoding/' xmlns:s='http://schemas.xmlsoap.org/soap/envelope/'><s:Body><u:$action xmlns:u='$uri'></u:$action></s:Body></s:Envelope>" -s > /dev/null |
(nicht selbst erfunden, sondern irgendwo abgeschaut. finde bloss nicht mehr wo…)
perl: warning setting locale failed unter debian
nach dem letzten update meines arbeitsplatz rechners mit linux mint, bekomme ich bei ssh verbindungen zu diversen servern bei perl basierten anwendungen meist sowas:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_MEASUREMENT = "de_DE.UTF-8",
LC_PAPER = "de_DE.UTF-8",
LC_MONETARY = "de_DE.UTF-8",
LC_NAME = "de_DE.UTF-8",
LC_ADDRESS = "de_DE.UTF-8",
LC_NUMERIC = "de_DE.UTF-8",
LC_TELEPHONE = "de_DE.UTF-8",
LC_IDENTIFICATION = "de_DE.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory
/usr/bin/locale: Cannot set LC_ALL to default locale: No such file or directory
da das problem nur bei ssh verbindungen auftritt, sollte beim ssh client die option SendEnv LANG LC_* in der datei /etc/ssh/ssh_config deaktiviert (auskommentiert) werden
ceph und festplattencontroller
man muss ja selbst seine erfahrungen machen mit ceph & co…. die leute von proxmox schreiben in ihren forumsbeitraegen auch immer, dass man seine hardware vor dem betrieb testen soll.
bei einer erweiterung meines ceph storages hab ich gedacht: oh… da ist ein adaptec raid controller drin. mit viel cache und ner backup batterie. und den kann man auch ohne raid betreiben, wenn man den in seinem bios in den HBA mode stellt. gesagt – getan. funktionierte auch erstmal. aber wenn man mal genauer hin schaut, ist die apply/commit latenz bei einigen OSDs um ein vielfaches hoeher, als bei den anderen. hier nur ein beispiel bild, bei dem die werte noch “relativ” niedrig waren. (die node in der mitte des screenshots)
tja – mein gedanke mit “der adaptec controller kanns doch bestimmt besser, als die schnoeden onboard sata dinger” … war dann wohl nix. die ceph doku schreibt “Disk controllers also have a significant impact on write throughput. Carefully, consider your selection of disk controllers to ensure that they do not create a performance bottleneck.”
also controller rausgerissen und die ganze sata kabelage ausgetauscht und die onboard intel controller benutzt…. und siehe da.. die latenz ist “normal”:
kann man auch wunderschoen beim “IO delay” (in blau) erkennen:
auch die proxmox doku schreibt dazu:
“Avoid RAID
As Ceph handles data object redundancy and multiple parallel writes to disks (OSDs) on its own, using a RAID controller normally doesn’t improve performance or availability. On the contrary, Ceph is designed to handle whole disks on it’s own, without any abstraction in between. RAID controller are not designed for the Ceph use case and may complicate things and sometimes even reduce performance, as their write and caching algorithms may interfere with the ones from Ceph.”
jaja… ist ja gut. wie immer erstmal vorher lesen. aber am besten lernt man natuerlich aus den eigenen fehlern 😉
linux: die seriennummer einer festplatte rausfinden
da gibt es mehrere moeglichkeiten. ein paar davon hier gelistet.
command:
udevadm info --query=all --name=/dev/sda | grep ID_SERIAL_SHORT |
output:
E: ID_SERIAL_SHORT=1828E1487BE33 |
command:
hdparm -I /dev/sda | grep 'Serial\ Number' |
output:
Serial Number: 1828E1487BE33 |
command:
lshw -class disk|grep serial |
output:
serial: 1828E1487BE33 |
command:
smartctl -i /dev/sda | grep Serial |
output:
Serial Number: 1828E1487BE33 |
command:
lsblk --nodeps -o name,serial|grep sda |
output:
sda 1828E1487BE33 |
command:
ls -al /dev/disk/by-id/|grep -e sda$|grep -v wwn |
output:
lrwxrwxrwx 1 root root 9 Nov 13 05:23 ata-CT500MX500SSD1_1828E1487BE33 -> ../../sda |
wo finde ich die exchange web services (EWS) url?
um die URL der exchange webservices rauszufinden, gibt es (mindestens) zwei moeglichkeiten:
entweder in der exchange management shell auf dem exchange server dieses kommando ausfuehren:
Get-WebServicesVirtualDirectory |Select name, *url* | fl
sieht dann ungefaehr so aus:
oder clientseitig mit der rechten maustaste auf das try-icon von outlook klicken und “Test E-mail Auto Configuration” auswaehlen. sieht dann so aus:
entweder auf deutsch die “URL für Verfügbarkeitsdienst” oder auf englisch “Availability Service URL”
