Tag: linux

no matching key exchange method found

nach update eines “jumphosts” scheiterte die verbindung zu einer leider noch vorhandenen urlat linux kiste mit folgender fehlermeldung:

Unable to negotiate with 10.x.x.x port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

damit die verbindung doch noch irgendwie klappt ist eine moeglichkeit fuer diesen host “ausnahmen” zu definieren. dazu einfach eine datei “/etc/ssh/ssh_config.d/hostname.conf” anlegen mit folgendem inhalt

Host hostname
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc

Host xxx.xxx.xxx.xxx
  KexAlgorithms +diffie-hellman-group1-sha1
  Ciphers +aes128-cbc

opnsense festplatte vergroessern

ohne grosse worte…

root@f1:~ # gpart show /dev/da0
=> 40 27262896 da0 GPT (13G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 14680056 3 freebsd-ufs (7.0G)
15090720 12172216 - free - (5.8G)

root@f1:~ # gpart resize -i 3 da0
da0p3 resized

root@f1:~ # gpart show /dev/da0
=> 40 27262896 da0 GPT (13G)
40 409600 1 efi (200M)
409640 1024 2 freebsd-boot (512K)
410664 26852272 3 freebsd-ufs (13G)

root@f1:~ # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 6.8G 5.2G 1.0G 83% /
devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /var/dhcpd/dev

root@f1:~ # growfs /dev/gpt/rootfs
Device is mounted read-write; resizing will result in temporary write suspension for /.
It's strongly recommended to make a backup before growing the file system.
OK to grow filesystem on /dev/gpt/rootfs, mounted on /, from 7.0GB to 13GB? [yes/no] yes
super-block backups (for fsck_ffs -b #) at:
15387072, 16669312, 17951552, 19233792, 20516032, 21798272, 23080512, 24362752, 25644992

root@f1:~ # df -h
Filesystem Size Used Avail Capacity Mounted on
/dev/gpt/rootfs 12G 5.2G 6.2G 45% /
devfs 1.0K 1.0K 0B 100% /dev
devfs 1.0K 1.0K 0B 100% /var/dhcpd/dev

dovecot maildir subscriptions file erstellen

“irgendwie” kam mir im dovecot maildir meine subscriptions datei abhanden πŸ˜‰

und bevor ich meine maus kaputt mache, wenn ich 1384347 unterordner einzeln anklicken muss… dann lieber per script im maildir verzeichnis:

find . -maxdepth 1 -type d | grep --color=NEVER "\./\." | sed -e 's|\./\.||g' > subscriptions

endlich pxe ;-)

wollte ich schon immer mal haben… die letzten tage hab ich dann immer mal wieder etwas gebastelt. nun kann im heimnetzwerk von pxe gebootet werden.

diverse rettungssysteme und so zeugs, was man halt braucht werden direkt uebers netz vom nas gebootet. wenn man das noch nie gemacht hat, war das teilweise echt frickelig. aber wenns dann erstmal klappt…

anleitungen dazu werde ich vermutlich nicht machen. hab da ein paar gute gefunden.
einen raspi4 hab ich auch schon dazu gebracht via pxe zu booten. das gefrickel mit den speicherkarten hat mich genervt. ausserdem gehen die irgendwann kaputt. der raspi wird ein thinclient fuers homeoffice πŸ˜‰

mal ne runde ssd’s getauscht…

momentan laufen im “home rz” um die 35 VMs.. und der plattenplatz ging langsam zu neige. (ein ceph cluster darf man ja nie voll machen!)
also mal schlappe 15 stueck 1 tb ssds gekauft und die 500 gb dinger im laufenden betrieb eine nach der anderen ausgetauscht.

das reicht mir wieder ne ganze weile πŸ™‚

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 "" -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

citrix: error cannot connect to 0.0.0.2

ich musste unter linux (mint) mit der citrix workspace app arbeiten. beim laden der ica-datei kam der fehler “error cannot connect to 0.0.0.2 appname”. hier die loesung… irgendwo beim googlen gefunden… weiss nur nicht mehr wo:

cd /opt/Citrix/ICAClient/keystore/
sudo rm -r cacerts
sudo ln -s /etc/ssl/certs cacerts