(160 MB) 00:25:56
2017-02-22 15:56 🛈Da die Konstruktion aus vergangenen Zeiten nur bedingt hält zeige ich mal wieder wie schlecht meine Hermwerkerkünste sind und improvisiere aus den Resten ein Regal für den Basteltisch
(160 MB) 00:25:56
2017-02-22 15:56 🛈Da die Konstruktion aus vergangenen Zeiten nur bedingt hält zeige ich mal wieder wie schlecht meine Hermwerkerkünste sind und improvisiere aus den Resten ein Regal für den Basteltisch
(91 MB) 00:23:29
2017-02-19 11:00 🛈Der Onion Omega 2 ist ein kleines und günstiges Bastelboard, welches sich zwischen kleinen Mikrocontrollern wie Arduino/ESP8266 und den großen Mini-Computern wie dem Raspberry Pi platziert. Mit 580MHz, 64MB RAM und integriertem WLAN wird er für „Internet of Things“-Anwendungen angepriesen.
In diesem Video werden wir einen Blick auf die technischen Daten werfen, uns die Einrichtung anschauen und letztendlich mittels OctoPrint dem 3D-Drucker der letzten Folge ein Webinterface verpassen.
Inhalt
Links
Diese Meldung weist erst mal darauf hin, dass die Installation beschädigt ist. Dies kommt häufig vor, wenn der Updater unterbrochen wird oder ein übereifriger Virenscanner genutzt wird. Eine Reparaturinstallation ist meist keine schlechte Idee – hierzu einfach die aktuelle Installation von der Webseite ohne vorherige Deinstallation ausführen. E-Mails und Einstellungen bleiben hierbei zu großen Teilen erhalten. Zeigt dies keine Wirkung kann auch ein Blick auf die Dateirechte nicht schaden – in meinem Fall war für den Ordner bzw. dessen Dateien das Execute-Recht verweigert.
(305 MB) 00:50:02
2017-02-12 11:00 🛈Der 101hero wird vom Macher als günstigster jemals verkaufter 3D-Drucker angepriesen. Im Rahmen des Crowdfundings waren die Geräte teils für 49$ zu bekommen. Für einen 3D-Drucker eine Kampfansage, denn die meisten Bausätze fangen erst bei über 200€ an. Natürlich kommt der Preis mit Abstrichen: Die bebaubare Fläche ist mit 15x15x10cm recht klein, die mit Getriebe ausgestatteten Schrittmotoren haben deutlich weniger Geschwindigkeit und Präzision als die üblicherweise verwendeten NEMAs und auch der Plastikaufbau verspricht nicht gerade eine hohe Stabilität.
Während man den Liefertermin Oktober Crowdfunding-Typisch nicht halten konnte gehen die Geräte langsam in den Versand und einer der Kartons ist auch bei mir eingetroffen. Schauen wir mal, ob man für den Preis tatsächlich irgendeine Funktion erhält.
Business as usual: Pünktlich zum Jahresanfang wird man von sämtlichen Vertragspartnern mit totem Baum zugeworfen. Glücklicherweise habe ich passende Scanner, die das Material in etwas besser verwaltbare Formen überführen können. Zuletzt verwendete ich dazu einen Panasonic/Matsushita KVS-5026, welchen ich aus dem Schrott retten konnte. Zwar habe ich noch einige schnellere Modelle, dieser hatte jedoch bisher die wenigsten Probleme mit Double-Feeding und ist durch die Bauform bei mir einfacher zu nutzen.
Leider war der Start dieses Jahr nicht ganz so erfolgreich – der Scanner wird korrekt erkannt, versuchte ich jedoch einen Scan zu starten gab es den allseits beliebten „Segmentation fault“. Boo.
Der Trick des letzten Problems half dieses mal leider nicht – auch die aktuelle GIT-Version zeigen den selben Fehler. Da es für das passende Backend kvs20xx keinen Maintainer gibt ist wohl auch keine Besserung zu erwarten.
OK, ich bin kein C-Programmierer, habe keine Ahnung von Debuggern unter X86 und produziere auch sonst eher nicht qualitätsorientieren Code – was kann schon schief gehen.
Ein paar Debug-Textausgaben später konnte ich den Fehler auf die Funktion sane_open, genauer die erste „echte“ Codezeile dort „for (i = 0; devlist[i]; i++)“ eingrenzen. Offenbar wurde früher durch sane automatisch ein Scan iniziiert und die devlist daher gefüllt. In der aktuellen Version scheint es beim Aufruf leer zu sein und mit NULL hantieren mag C wohl nicht. Als workaround konnte ich ein paar Zeilen des Fujitsu-Treibers ruberkopieren, welche die Inizialisierung ggf. nachholen. Auch diese musste etwas angepasst werden um mit dem direkten Aufruf umgehen zu können. Immerhin: Der Scanner läuft und ich kann weitermachen. Fein.
diff --git a/backend/kvs20xx.c b/backend/kvs20xx.c index 955252a3..56095cb5 100644 --- a/backend/kvs20xx.c +++ b/backend/kvs20xx.c @@ -1,6 +1,8 @@ /* Copyright (C) 2008, Panasonic Russia Ltd. Copyright (C) 2010, m. allan noah + + Attn: Local workaround 2017-02-11 Florian Knodt, sane-kvs@adlerweb.info */ /* Panasonic KV-S20xx USB-SCSI scanners. @@ -141,6 +143,8 @@ sane_get_devices (const SANE_Device *** device_list, devlist = NULL; } + sanei_usb_init(); + for (curr_scan_dev = 0; curr_scan_dev < sizeof (known_devices) / sizeof (known_devices[0]); curr_scan_dev++) @@ -156,7 +160,10 @@ sane_get_devices (const SANE_Device *** device_list, known_devices[curr_scan_dev].scanner.model, NULL, -1, -1, -1, -1, attach); } - *device_list = (const SANE_Device **) devlist; + + if(device_list && devlist){ + *device_list = (const SANE_Device **) devlist; + } return SANE_STATUS_GOOD; } @@ -168,10 +175,22 @@ sane_open (SANE_String_Const devname, SANE_Handle * handle) struct scanner *s; SANE_Int h, bus; SANE_Status st; + + if (devlist) { + DBG (DBG_INFO, "Using prepopulated device list\n"); + }else{ + DBG (DBG_INFO, "Device list empty - scanning...\n"); + st = sane_get_devices(NULL,0); + if(st != SANE_STATUS_GOOD){ + DBG (DBG_WARN, "Scan failed\n"); + return st; + } + } + for (i = 0; devlist[i]; i++) { if (!strcmp (devlist[i]->name, devname)) - break; + break; } if (!devlist[i]) return SANE_STATUS_INVAL;
Debian mag stabil sein, der aktuell bei Jessie mitgelieferte 3.16er Kernel wird von einigen Dingen jedoch nicht mehr unterstützt, die Installation dieser Softwarepakete ist also nicht mehr möglich. Glücklicherweise gibt es die so genannten Backports, welche neuere Versionen bereitstellen. Nicht ganz so gut getestet, aber immerhin eine Möglichkeit.
Die Einrichtung geht recht schnell – man muss lediglich folgende Zeile in /etc/apt/sources.list hinzufügen:
deb http://ftp.debian.org/debian jessie-backports main
Sucht man nun nach linux-image, also dem Kernel, findet man auch einige neue Versionen. In meinem Fall ist die 4.9.0 aktuell:
# apt-cache search linux-image ... linux-image-4.9.0-0.bpo.1-amd64 ...
Leider gelingt die Installation nicht ohne Klimmzüge, denn der erste Versuch wird mit einer Fehlermeldung quittiert:
# apt-get install linux-image-4.9.0-0.bpo.1-amd64 linux-headers-4.9.0-0.bpo.1-amd64 Paketlisten werden gelesen... Fertig Abhängigkeitsbaum wird aufgebaut. Statusinformationen werden eingelesen.... Fertig Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass Sie eine unmögliche Situation angefordert haben oder, wenn Sie die Unstable-Distribution verwenden, dass einige erforderliche Pakete noch nicht erstellt wurden oder Incoming noch nicht verlassen haben. Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen: Die folgenden Pakete haben unerfüllte Abhängigkeiten: linux-image-4.9.0-0.bpo.1-amd64 : Hängt ab von: linux-base (>= 4.3~) aber 3.5 soll installiert werden Empfiehlt: firmware-linux-free soll aber nicht installiert werden Empfiehlt: irqbalance soll aber nicht installiert werden E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
Auf den ersten Blick scheint es jedoch keine neue Verison des Paketes zu geben:
linux-base is already the newest version.
Ursache ist die Priorisierung: Sowohl im „offiziellen“ Jessie-Repository als auch in den Backports steckt ein Paket mit dem Namen linux-base. Zwar ist jenes in den Backports aktueller, jedoch werden die Pakete des Stable-Repos bevorzugt. Abhilfe schafft es das Paket explizit aus dem Backports-Repo zu beziehen.
apt-get -t jessie-backports install linux-base
Im Anschluss ist auch die Installation des Kernels fehlerfrei möglich. Mit dieser Methode kann man auch das Kernel-Metapaket installieren um zukünftige Updates automatisch zu erhalten:
apt-get -t jessie-backports install linux-image-amd64
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.
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.
(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.
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