ZFS/ZOL: Pool UNAVAIL nach Reboot

Nicht schön. Nach dem Reboot eines Server musste ich feststellen, dass diverse Storages nicht mehr zugreifbar waren. Schnell stellte sich heraus, dass alle ZFS-Pools offline waren und die Geräte mit der Meldung „too many errors“ als FAULTED markiert wurden.

 zpool import
   pool: tempstore
     id: xyz
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        tempstore   UNAVAIL  insufficient replicas
          sdd       FAULTED  too many errors
          sde       FAULTED  too many errors

   pool: storage
     id: xyy
  state: UNAVAIL
 status: One or more devices are faulted.
 action: The pool cannot be imported due to damaged devices or data.
 config:

        storage     UNAVAIL  insufficient replicas
          sdb       FAULTED  too many errors

Nunja, Consumer-Platten traue ich ja viele defekte zu, aber drei unabhängige Platten gleichzeitig? Eher nein. Auch S.M.A.R.T. zeigte keine wirklich bedenkenswerten Werte. Aufschlussreicher ist da schon das Kernel-Log:

[  776.890127] Large kmem_alloc(131128, 0x1000), please file an issue at:
               https://github.com/zfsonlinux/zfs/issues/new
[  776.890129] CPU: 1 PID: 12969 Comm: vdev_open Tainted: P           O    4.4.39-gentoo-adlerweb #2
[  776.890130] Hardware name: LENOVO yxz/        , BIOS xyz 01/10/2012
[  776.890132]  0000000000000000 ffff880417a37bc0 ffffffff813545d8 000000000240c200
[  776.890134]  0000000000000000 ffff880417a37c00 ffffffffa0018af1 0000000017a37be0
[  776.890138]  0000000000000000 ffff88041626d480 ffff8804174ed660 0000000000004000
[  776.890139] Call Trace:
[  776.890144]  [<ffffffff813545d8>] dump_stack+0x4d/0x65
[  776.890148]  [<ffffffffa0018af1>] spl_kmem_zalloc+0x131/0x180 [spl]
[  776.890163]  [<ffffffffa0109aa8>] vdev_cache_stat_fini+0x258/0xcc0 [zfs]
[  776.890175]  [<ffffffffa010a3ba>] vdev_cache_stat_fini+0xb6a/0xcc0 [zfs]
[  776.890188]  [<ffffffffa014426a>] zio_data_buf_free+0x51a/0xdc0 [zfs]
[  776.890200]  [<ffffffffa014798f>] zio_nowait+0xaf/0x190 [zfs]
[  776.890215]  [<ffffffffa0104cce>] vdev_probe+0xfe/0x200 [zfs]
[  776.890228]  [<ffffffffa01059e0>] ? vdev_accessible+0x70/0x2b0 [zfs]
[  776.890240]  [<ffffffffa0107969>] vdev_open+0x3c9/0x4b0 [zfs]
[  776.890251]  [<ffffffffa0107bdd>] vdev_open_children+0x18d/0x1c0 [zfs]
[  776.890254]  [<ffffffffa001b8ec>] taskq_dispatch+0x3ac/0x5b0 [spl]
[  776.890257]  [<ffffffff810c1ed0>] ? wake_up_q+0x70/0x70
[  776.890261]  [<ffffffffa001b6e0>] ? taskq_dispatch+0x1a0/0x5b0 [spl]
[  776.890263]  [<ffffffff810b8c04>] kthread+0xc4/0xe0
[  776.890265]  [<ffffffff810b8b40>] ? kthread_park+0x50/0x50
[  776.890268]  [<ffffffff81a6a5df>] ret_from_fork+0x3f/0x70
[  776.890270]  [<ffffffff810b8b40>] ? kthread_park+0x50/0x50

*kick* Da war ja was. ZOL läuft wegen der Lizenzproblematik als Kernel-Modul. Ich hatte zuletzt am Kernel einige Treiber nachgezogen. Hierbei sind zwar Version und Ablageort gleich geblieben, offenbar ist aber die ABI etwas gewandert, sodass SPL/ZFS etwas verwirrt den Dienst quittierten.

Für Gentoo heißt das einmal Module neu Bauen, in meinem Fall

emerge -va spl zfs-kmod

 

Alternativ und in den meisten Fällen zuverlässiger ist es nach jeder Kernel-Änderung alle Module automatisch neu zu erstellen:

emerge -va @module-rebuild

Storage online, Admins glücklich, Update-Doku ergänzt. Passt.

vSphere vCenter Server Appliance (vCSA) 6.0 -> 6.5 VIX Upgrade Fehler

Beim Upgrade einer vCSA 6.0 zu 6.5 ergeben sich die tollsten Fehlermeldungen – und keine ist dokumentiert. Immerhin eine konnte ich Dank des VMWare-Forums schnell herausfinden:

"A problem occurred while getting data from the source vCenter Server."

Selbstverständlich waren die Zugangsdaten des Quellserver korrekt und funktionierten in WebUI bzw. SSH fehlerfrei. Ich übersetze mal in eine für Administratoren verständliche Sprache:

"Kennwort abgelaufen"

Nachdem ein neues Kennwort vergeben wurde läuft das Update an dieser Stelle weiter.

Nutzung von GIT auf Debian/Ubuntu nicht möglich: GnuTLS

(Anm: Angeblich soll der Bug inzwischen behoben sein)

Debian und dessen Devirate geben sich zur Zeit wieder eine Menge Mühe meine Vorurteile zu erfüllen. Dieses mal hat es GIT erwischt: Beim Klonen eines Repositories kommt es zu einem Verbindungsfehler durch GnuTLS.


2$ git clone https://github.com/freifunk-gluon/gluon.git gluon -b v2016.2.2
Klone nach 'gluon' ...
fatal: unable to access 'https://github.com/freifunk-gluon/gluon.git/': gnutls_handshake() failed: Public key signature verification has failed.

Offenbar hat die bei Debian mitgelieferte Version von GnuTLS Probleme mit einigen Cipher-Suites und Proxyservern. Ich folge mal den Tipps von Nyambaa@AskUbuntu bzw. xmendez und habe GIT statt mit GnuTLS gegen OpenSSL gebaut:

apt-get update
apt-get install build-essential fakeroot dpkg-dev libcurl4-openssl-dev
apt-get build-dep git
mkdir /usr/src/git/
cd /usr/src/git
apt-get source git
dpkg-source -x git_2.1.4-2.1+deb8u2.dsc
cd git-2.1.4

Die Version muss natürlich der jeweils aktuellen angepasst werden – lässt sich ggf. per ls nach apt-get source herausfinden.

In der Datei debian/control muss nun überall der Text libcurl4-gnutls-dev gegen libcurl4-openssl-dev ersetzt werden. Im Anschluss wird das Paket gebaut und installiert. Ggf meckert buildpackage noch über fehlende libraries, welche man schnell per apt-get nachziehen kann.

dpkg-buildpackage -rfakeroot -b
dpkg -i git_2.11.0+next.20161205-1_amd64.deb git-man_2.11.0+next.20161205-1_all.deb

Nun sollte das installierte git auf OpenSSL basieren und keine Verbindungsprobleme mehr zeigen.

VMWare vMotion auf VMA per CLI auslösen

Kleines Script zwischendurch: Über dieses Perl-Konstrukt kann man auf einem vSphere Management Assistant eine vMotion auf der Konsole auslösen. So lassen sich recht einfach eventgesteuerte vMotion-Aktionen umsetzen. Ich nutze es z.B. um zeitgesteuert VMs an Standorte mit höherer erwarteter Hitrate zu verlegen oder bei Störungen kritische VMs automatisiert auf „sicherere“ Hosts zu migrieren. Das Original stammt von William Lam, ich habe einige Punkte etwas umgebaut um Storage-vMotion auszuklammern. Üblicher Disclaimer: Proof of concept, keine Garantie, nicht-Programmierer-versucht-sich-an Perl, Works for me.

#!/usr/bin/perl -w

# Reworked for standard vmotion: Florian Knodt - https://www.adlerweb.info

# Original for distinct storage: William Lam - http://blogs.vmware.com/vsphere/automation

use strict;

use warnings;

use VMware::VILib;

use VMware::VIRuntime;

use Data::Dumper;

my %opts = (

    vmname => {

        type => "=s",

          help => "Name of Virtual Machine to migrate",

        required => 1,

    },

    vihost => {

          type => "=s",

          help => "Name of ESXi host to migrate to",

          required => 1,

     },

    priority => {

        type => "=s",

          help => "Migration priority [high|low]",

          required => 0,

        default => 'high',

    },

);

Opts::add_options(%opts);

Opts::parse();

Opts::validate();

Util::connect();

my $vmname = Opts::get_option('vmname');

my $vihost = Opts::get_option('vihost');

my $priority = Opts::get_option('priority');

if(Vim::get_service_content()->about->apiVersion lt "5.1") {

    &seeya("Script requires vCenter Server >5.1\n");

}

# define priority enums

my %priorityConstants = ('high' => 'highPriority', 'low' => 'lowPriority');

# retrieve VM

my $vm_view = Vim::find_entity_view(view_type => 'VirtualMachine', filter => {'name' => $vmname}, properties => ['name']);

if(!defined($vm_view)) {

    &seeya("Unable to find VM: " . $vmname . "\n")

}

# retrieve host

my $host_view = Vim::find_entity_view(view_type => 'HostSystem', filter => {'name' => $vihost}, properties => ['name']);

if(!defined($host_view)) {

    my $test = Vim::find_entity_view(view_type => 'HostSystem', properties => ['name']);

    print Dumper($test);

    &seeya("Unable to find ESXi host: " . $vihost . "\n");

}

# in case bad input

if($priority ne "low" || $priority ne "high") {

    $priority = "high";

}

$priority .= "Priority";

my ($task,$message);

eval {

    # call migrate API

    print "Migrating " . $vmname . " to ESXi Host: " . $vihost . "...\n";

    $task = $vm_view->MigrateVM_Task(host => $host_view, priority => VirtualMachineMovePriority->new($priority));

    $message = "Successfully migrated " . $vmname . "!\n";

    &getStatus($task,$message);

};

if($@) {

    print "Error: " . $@ . "\n";

}

Util::disconnect();

sub getStatus {

     my ($taskRef,$message) = @_;

     my $task_view = Vim::get_view(mo_ref => $taskRef);

     my $taskinfo = $task_view->info->state->val;

     my $continue = 1;

     while ($continue) {

        my $info = $task_view->info;

        if ($info->state->val eq 'success') {

                print $message,"\n";

                return $info->result;

                $continue = 0;

        } elsif ($info->state->val eq 'error') {

                my $soap_fault = SoapFault->new;

                $soap_fault->name($info->error->fault);

                $soap_fault->detail($info->error->fault);

                $soap_fault->fault_string($info->error->localizedMessage);

                die "$soap_fault\n";

        }

        sleep 5;

        $task_view->ViewBase::update_view_data();

     }

}

sub seeya {

    my ($message) = @_;

    print $message;

    Util::disconnect();

    exit 1;

}

Aufruf:

./scriptname.pl --server vcenter.domain.local --username admin --password admin --vmname MyVM --vihost esxihost2.domain.local

BitBastelei #229 – ICStation.com RF24 Funkmodule

BitBastelei #229 - ICStation.com RF24 Funkmodule

(32 MB) 00:15:01

2017-02-05 11:00 🛈

RF24-Module sin ein guter Kompromiss um günstig und einfach Daten mit einem Mikrocontroller wie dem Arduino per Funk zu übertragen. Das Modul übernimmt dabei viele Aufgaben zur Sicherstellung einer korrekten Übertragung, sodass der µC weniger Aufgaben erledigen muss.

Mit dem Rabattcode: bitics gibt es 15% Rabatt auf das Sortiment von ICStation

BitBasics: Funk-Datenübertragung per Mikrocontroller

BitBasics: Funk-Datenübertragung per Mikrocontroller

(36 MB) 00:15:02

2017-02-05 11:00 🛈

Nicht immer kann ein ein Kabel legen um Daten eines Mikrocontrollers wie dem Arduino zu ihrem Ziel zu bringen. Hier zeige ich die bekanntesten Möglichkeiten um mit Mikrocontrollern Daten drahtlos zu übertragen.

Arch Linux / Arduino: libtinfo.so.5 fehlt

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/02/archarduino-300×58.pngBei der Nutzung der Arduino-IDE kommt es zur Zeit unter Arch Linux zu Problemen in Zusammenhang mit AVR-Boards. Ursache ist, dass Arduino seit einigen Versionen nicht mehr die Tools des System nutzt, sondern auf vorkompilierte Binärdateien setzt. Diese Alles-dabei-Conteiner versprechen auf den ersten Blick eine Vereinfachung, fliegt aktuell leider etwas auseinander: Die beigelegten Programme sind an vielen Stellen gegen überholte Bibliotheken gebaut. Dies verschafft zwar Kompatibilität mit trägen Systemen wie z.B. Debian, macht eine Nutzung mit aktuellen Systemen umständlich.

Schaut man sich die Fehlermeldung genauer an findet man schnell heraus, dass der beigelegte avrdude die Probleme auslöst:

avrdude: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or director

Libtinfo wurde zwischenzeitlich wohl in Ncurses übernommen, zudem benötigt Arduino/avrdude eine ältere, normalerweise nicht mehr installierte API der ncurses-Library.

Wer die Libraries passend haben möchte muss zuerst ncurses5-compat-libs installieren um die alten API-Versionen nachzurüsten, im Anschluss sorgt das Dummy-Paket libtinfo dafür die alten Dateinamen auf ncurses umzubiegen.

YubiKey: GPG-Kartenfehler / Sharing Violation unter Windows

Ugh – Windows und Sicherheitsfunktionen passt irgendwie immer noch nicht zusammen. Schon länger nutze ich einen YubiKey als GPG-Smartcard um E-Mails zu signieren und entschlüsseln. Das funktionierte mit GPG4Win und Thunderbird bisher auch recht brauchbar – also bis auf den Windows-GPG-Agent-Bug.

Wie gesagt: Bisher. Heute dann ein etwas seltsamer Bug:

# gpg --card-status
gpg: selecting openpgp failed: Card error
gpg: OpenPGP card not available: Card error

Wat. Schnell nochmal den Daemon durchstarten: Nix. Im Log findet man folgende Info:

scdaemon: pcsc_connect failed: sharing violation (0x8010000b)
scdaemon: reader slot 0: not connected

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/02/wp-1485952629803-300×225.jpgWait. Sharing violation? Greift sonst noch wer zu? Jepp, natürlich tut das Jemand. Ich hatte zwischenzeitlich auf dem YubiKey für ein anderes System X.509-Zertifikate (aka PIV) eingerichtet. Diese kommen z.B. zur Authentifizierung zum Einsatz und können unter Windows auch z.B. für Remote-Logins und das entschlüsseln von Bitlocker-Festplatten verwendet werden. Entsprechend hat nun also auch Windows die PIV-Smartcard gefunden und belagert das Device dauerhaft – somit ist der Zugriff für gpg nicht mehr möglich. Abhilfe schafft hier den Dienst „CertPropSvc“ (aka „Zertifikatverteilung“) zu beenden bzw. neuzustarten. In letzterem Fall bleibt das Gerät frei bis man die nächste Software mit PIV-Zugriff (z.B. Remotedesktop) startet.

Also als weiterer Punkt auf dem nicht enden wollenden Wunschzettel für einen würdigen Nachfolger für die leider sicherheitstechnisch bedenklich gewordenen YubiKeys: Parallelität der SC-Reader…

BitBasics – RAID

BitBasics - RAID

(56.6 MB) 00:22:00

2017-01-29 11:00 🛈

RAID beschreibt verschiedene Methoden um mehrere Speicher wie Festplatten oder SSDs zusammenzufassen um Geschwindigkeit oder Verfügbarkeit zu verbessern. Schauen wir uns die Arten und Implementierungen an.

BitBastelei #228 – TFT: Von CCFL auf LED umbauen

BitBastelei #228 - TFT: Von CCFL auf LED umbauen

(326.3 MB) 00:47:18

2017-01-22 11:00 🛈

Vor einiger Zeit hatte ich einen TFT für Betrieb an 12V umgerüstet. In den Kommentaren wies Iraklis darauf hin, dass man die CCFL-Röhren auch durch wesentlich sparsamere LEDs umbauen könnte. Challenge Accepted.

Die LEDs lassen sich mit den Suchworten „120LED/m“ oder „5m 600 LED“ finden.

Update: Bei der LED-Strommessung war der Inverter noch angeklemmt und verfälschte das Ergebnis – ohne sank der Strom um weitere 100mA, die Ersparnis ist somit bei etwa 38%.

Nerd Inside