chr.istoph, der Blog

Ubuntu 16.04 hat eine aktuelle Version von SSH mit an Bord. Hier bei sind die DSA Public Private Key nicht mehr unterstützt und es kommt beim aufrufen von ssh -v zu folgende Debugausgaben bzw. zu Passwort Eingabeaufforderung.

ssh root@server -v
OpenSSH_7.1p2 Ubuntu-2, OpenSSL 1.0.2f  28 Jan 2016
...
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Skipping ssh-dss key .ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
root@server's password:

Um dies wieder zu erlauben, muss in der /etc/ssh/ssh_config folgender Parameter hinzugefügt werden:

PubkeyAcceptedKeyTypes +ssh-dss

Um die Daten einer Festplatte zu retten auf unter anderem ein LVM Raid1 war, habe ich versucht mit vgchange -ay vg das vg zu starten. Andernfalls waren die LVS nicht unterhalb von /dev/mapper/ nicht aufgeführt.
Nach dem ich aber vgchange -ay vg aufrief war die Festplatte nur noch mit Lesezugriffen beschäftige. Die LVS waren vorhanden aber leisen sich nicht mounten. Somit habe ich den Vorgang mit vgchange -an vg wieder abgebrochen.

Um von hinten am LVM vorbei an die Daten heranzukommen half mir folgende Option mit der ich an die Festplatte bzw. die Position des lvs heran kam:

lvs -a -o +seg_pe_ranges|grep lv
LV   VG Attr       LSize   Convert PE Ranges
WARNING: Device for PV ZfExWH-u4Z9-zuqn-6e8P-ecDe-TYuQ-rBIlQP not found or rejected by a filter.
lv   vg owi-i-s---  40,00g dev/sdc3:38146-48385

In der Datei /etc/lvm/backup/vg fand ich zusätzlich noch folgend Informationen, alle anderen habe ich an dieser stelle ausgelassen:

vg {
        extent_size = 8192              # 4 Megabytes
        physical_volumes {
                pv0 {
                        device = "/dev/sdc3"    # Hint only
                        pe_start = 384          # Ofset

Mit diesen Werten kann man die Position des LVs auf der Festplatte lokalisieren und mit dmsetup einen eigenes device anlegen.

(48385-38146+1)*8192
(Partitionsende – Paritionsanfang + 1) * extent_size = ergibt die gesamt Größe: 83886080

384+38146*8192
pe_start + Paritionsanfang * extent_size begin auf der Parition: 312492416

echo "0 83886080  linear /dev/sdc3 312492416" | dmsetup create -r "lv_ro"

Unter /dev/mepper/lv_ro befindet sich nun das LV das gemountet werden kann.

Wie man an dieser stelle das readonly device mounten kann folgt im nächsten Blog Eintrag.

Zum prüfen ob Updates vorhanden sind, habe ich dein zabbix check geschrieben der mir nicht nur anzeigt wie viele Updates installiert werden können, sondern auch wie viele davon Sicherheitsupdates sind. Zudem wird angezeigt ob nach dem Installieren ein Neustart notwendig ist.

Das zabbix-check-dpkg Pakte befindet sich nun unter anderem in meinem repository und kann nach dem hinzufügen der Paketquellen mit folgenden Befehl, auf dem jeweiligen Server, installiert werden:

apt-get install zabbix-check-dpkg

Im Zabbix selbst muss dann nur noch das, nach der Installation, unter /usr/share/doc/zabbix-check-dpkg/examples/dpkg_passive_checks_zabbix_template.xml.gz befindliche Template einmalig im Zabbix Server importiert werden muss.

Quellcode: github.com/zabbix-deb/debs

Heute musst ich einer VM mehr Speicherplatz zuweisen. Da die VM auf einem DRBD Cluster lag bin ich folgendermaßen vorgegangen.

lvs
LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
vm1 vg1 -wi-ao--- 67,00g

1. auf beiden VM Host Systemen habe ich das LV vergrößert.

lvresize vg1/vm1 -L 135g

2. Anschließend habe ich auf dem Primary DRBD Konten das DRBD Online vergrößert.

drbdadm resize vm1

cat /proc/drbd
4: cs:SyncSource ro:Primary/Secondary ds:UpToDate/Inconsistent C r---a-
ns:86370276 nr:9144 dw:86259976 dr:3566560 al:274 bm:129 lo:2 pe:8 ua:8 ap:1 ep:1 wo:f oos:71188220
[>....................] sync'ed: 0.2% (69516/69628)Mfinish: 0:42:04 speed: 28,192 (28,192) K/sec

Schon während der Synchronisation stand der vergrößerte Platz in der VM zur Verfügung.

Bei einem LVM Basierten KVM Server konnte ich eine VM nicht Starten. Das Kommando lvs zeigte an das ein Snapshot voll gelaufen sei.

sudo lvs
  LV         VG Attr   LSize   Origin  Snap%  Move Log Copy%  Convert
  windows    vg owi-i-  40,00g                                       
  windows_81 vg swi-i-  40,00g windows 100,00

Da ich den Rechner aber zuvor gebootet hatte und dies vor dem Reboot nicht der Fall war. Zudem greift meine VM nicht auf das Snapshot zu, so bin ich auf die Suche nach dem Fehler gegangen und geholfen hat folgender Befehl:

sudo lvchange -ay /dev/vg/windows

Quelle: man bash
--ignorelockingfailure
This lets you proceed with read-only metadata operations such as
lvchange -ay and vgchange -ay even if the locking module fails.
One use for this is in a system init script if the lock
directory is mounted read-only when the script runs.

Und schon wurde auch das LV wieder richtig angezeigt und konnte von KVM wieder gelesen werden.

sudo lvs
  LV         VG Attr   LSize   Origin  Snap%  Move Log Copy%  Convert
  windows    gw owi-ao  40,00g                                       
  windows_81 gw swi-a-  40,00g windows  73,22