Verlanglijstje

Deze keer:

  • Een nieuw kussen, of in ieder geval het luchtige schuimrubber aan de binnenkant, voor mijn fiets;
  • Een abonnement op Ars Technica, met een NFC-security-key;
  • Een prettige rugzak, met meerdere compartimenten en heup-riem;
  • Een stofzuigrobotje?

Print this entry

HP Photosmart D7160 0x18a0001 – ink system

Met de beschrijving op https://h30434.www3.hp.com/t5/Printing-Errors-or-Lights-Stuck-Print-Jobs/Ink-system-failed-Error-Oxc18a0101-on-photosmart-D7160/m-p/27071#M231430

Fix your HP Photosmart D7360 (Reset Code/Master Reset)

1- Turn off power and unplug from power source.
2- Open right side of printer (looking at the front).
3- Disconnect,by pulling gently, both white flat ribbon cables off the main circuit board.
4- Plug in power source and turn printer on. Wait till you get a error message and push “Ok”.
5- Unplug power source.
6- Reconnect the flat ribbon cables by aligning and carefully pushing into the conectors on the main circuit board.
7- Plug in power source and turn printer on (Printer preparing occurred).
8- voila, the nasty error message 0xc18a0001 “Ink System has Failed” is now gone. http://www.fixya.com/support/t451942-help    THIS WORKED!!!  Don’t throw it out try this first for: Ink system failed Error:Oxc18a0101 on photosmart D7160. 

Het is best lastig de zijkant te verwijderen. Er zitten een paar schroeven in, en na het verwijderen van de schroeven zitten er weerhaakjes voor eenmalig vastzetten en niet meer losmaken. Door met beleid kracht toe te passen, is de zijkant te verwijderen zonder al te veel clips af te breken.

Een andere optie vond ik op http://www.ccl-la.com/blog/index.php/hp-photosmart-ink-system-failure-2

HP PhotoSmart “Ink System Failure” #2

January 20, 2010 by CCL_TECH
Filed under: Uncategorized 

For HP PhotoSmart and Deskjet printers without Fax capabilities, use this guide.
Are you experiencing the ink system failure on your printer? The error is
caused by air getting in the ink tubes feeding the system. This is normally
cause by refilled cartridges but can be caused by any cartridge that goes very
low on ink and then tries to reload ink. This reset procedure does have to be
performed with a full cartridge installed. The following reset procedure will
correct the issue by purging the ink tubes and flushing any air trapped in them.

This sequence works if you have a C3110, C3210 or C3310 series printer. This
reset procedure should also work on any printer without FAX capabilities.
 
Please perform the following steps in order:
1. Make sure you have new cartridges in the printer so that it can reset
2. Press down the OK and Cancel buttons down at the same time and turn the
printer
off.
3. Keep holding the buttons down until the printer turns off.
4. Release the buttons.
5. Now turn the printer on while pressing the OK and Cancel buttons. It should cycle a bit then
turn back off.
6. Turn the unit on again.
7. After the second time off/on the printer will recalibrate the ink cartridges,
this will take about 5 minutes.
8. After calibration it should be online ready to print. Print a test page to
verify operation.

You should be back up and running. If this procedure does not solve the problem
then remove the cover from the printer and check the small white gear on the end
of the ink pump. The gear can come off after heavy use, just push it back on and
then redo the reset precedure as described above.


Print this entry

Proxmox op Debian

Proxmox biedt een ‘bare metal’ installer, waarmee automatisch het hele systeem klaargezet wordt. Mijn eerste Proxmox-server heb ik op die manier geinstalleerd.

Voor de huidige server zou ZFS een goede keuze kunnen zijn, maar met slechts 4GB aan RAM is het al wat krap voor alleen Proxmox en enkele containers. ZFS staat er om bekend beter te werken als het zwemt in beschikbaar geheugen, omdat ik dat onvoldoende kan inschatten wil ik voor deze installatie geen ZFS gebruiken.

‘Geen ZFS’ betekent ‘geen kant-en-klare’ installer. Gelukkig is het niet heel veel werk om een standaard Debian-installatie uit te breiden met Proxmox. De kale Debian installatie zat rond 100MB geheugengebruik. Ik volg een stappenplan van de Proxmox-website. In grote lijnen:

  • Machine in elkaar zetten
  • Debian installeren.
  • Afhankelijkheden in inrichting goedzetten:
    • /etc/hosts aanpassen om het externe IP terug te geven
    • /etc/apt/sources* uitbreiden met de repositories van Proxmox
  • Proxmox installeren met apt install proxmox-ve postfix open-iscsi
    • De download is ~350MB, installatie voegt ~1800MB toe.
  • Klaar!
    • Nog te doen: rechten instellen, containers maken, systeem gebruiken
# df -hTt ext4
Filesystem                   Type  Size  Used Avail Use% Mounted on
/dev/mapper/snelsys-root     ext4  2.7G   13M  2.6G   1% /
/dev/mapper/snelsys-usr      ext4  7.3G  1.1G  5.9G  15% /usr
/dev/sde2                    ext4  163M   83M   68M  55% /boot
/dev/mapper/slowsys-var      ext4  2.7G  153M  2.4G   6% /var
/dev/mapper/slowsys-varcache ext4  1.8G   77M  1.7G   5% /var/cache
/dev/mapper/slowsys-varlog   ext4  1.8G   24M  1.7G   2% /var/log
root@thuis:~# apt install proxmox-ve postfix open-iscsi
0 upgraded, 494 newly installed, 1 to remove and 0 not upgraded.
Need to get 342 MB of archives.
After this operation, 1,742 MB of additional disk space will be used.
Do you want to continue? [Y/n] 

Het liep fout; er was niet voldoende ruimte op /boot. Op de andere server is er 800MB in gebruik voor ’tig’ kernels, dat leek me wat overdreven. Hier zijn het er drie, daarvan kan er op zijn minst eentje per direct weg.

# dpkg -l | grep linux-image | awk '{print$2}'
linux-image-4.19.0-13-amd64
linux-image-4.19.0-6-amd64
linux-image-amd64
root@thuis:~# uname -a
Linux thuis 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28) x86_64 GNU/Linux
# apt remove --purge linux-image-4.19.0-6-amd64
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  linux-image-4.19.0-6-amd64*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 269 MB disk space will be freed.
Do you want to continue? [Y/n] 
...
update-initramfs: Deleting /boot/initrd.img-4.19.0-6-amd64
/etc/kernel/postrm.d/zz-pve-efiboot:
Re-executing '/etc/kernel/postrm.d/zz-pve-efiboot' in new private mount namespace..
No /etc/kernel/pve-efiboot-uuids found, skipping ESP sync.
/etc/kernel/postrm.d/zz-update-grub:
Generating grub configuration file ...
...
update-initramfs: Generating /boot/initrd.img-5.4.78-2-pve
Running hook script 'zz-pve-efiboot'..
Re-executing '/etc/kernel/postinst.d/zz-pve-efiboot' in new private mount namespace..
No /etc/kernel/pve-efiboot-uuids found, skipping ESP sync.
# 

Op / is er nauwelijks wat geinstalleerd, het iz vooral /usr waar ~1500MB aan toegevoegd is (1200 netto verschil, na purge oude kernel).

Rechten toewijzen

De Proxmox-installer maakt geen gebruikers aan. De Debian-installer wel. Bovendien heb laat ik de Debian-installer root-login uitschakelen. Zodoende is de bestaande gebruiker geen gebruiker die toegang tot Proxmox heeft.

Om Proxmox via de web-interface te bedienen, moet de gebruiker ingericht worden:

# pveum user add ikzelf@pam
# pveum groupadd beheer -comment "Proxmox en containers instellen"
# pveum aclmod / -group beheer -role Administrator
# pveum usermod ikzelf@pam -group beheer

De nieuwe rechten worden on-the-fly toegekend, maar bij het switchen tussen niveau’s op de web-interface komen maar enkele knoppen beschikbaar als je al ingelogd was voordat je aan de groep met ‘Administrator’-rol toegevoegd bent. Het was daarvoor in mijn geval niet voldoende uit- en in te loggen, of de pagina te verversen. De nieuwe eigenschappen werden pas zichtbaar na uitloggen, tab sluiten en inloggen in een nieuw tab.

Gegevensruimte / opslag

De servers heeft vier fysieke opslagmedia:

  • 1x SSD /dev/sde, 80GB
    • 9M BIOS boot, GPT-partitie voor GRUB
    • 170M /boot
    • 5.6G swap
    • 13G LVM PV
      • 13G VG ‘snelsys’
        • 2.8G LV root
        • 7.5G LV usr
    • 56G vrije ruimte
      • 3G ‘overprovisioning’, om de firmware ruimte te geven verwijderde bestanden op bestandssysteem-niveau, via LVM-pass-through als fysieke toewijzingen, de als leeg gemarkeerde sectoren te wissen. Als het goed is past de SSD-firmware dynamische wear-leveling toe, zodat die 3G vrije ruimte nomadisch over de flash-cellen rondwaart.
      • 50G+ voor read/write caching, ongeveer 10G/TB aan HDD-ruimte. Niet veel, maar het scheelt. Waarschijnlijk maak ik een enkele VG uit de twee vrije HDD’s, zodat de caching ineens voor alle LV’s voorbereid is. Misschien 1G voor VG slowsys, zodat alles onder /var SSD-caching heeft.
  • 1x HDD /dev/sda, 2TB, deels gebruikt:
    • 28G LVM PV
      • 28G VG ‘slowsys’
        • 2.8G LV var
        • 1.8G LV varcache
        • 1.8G LV varlog
    • ~2TB vrij, ik denk om een VG voor backups te maken
  • 2x HDD /dev/sdb en /dev/sdc, ieder 2TB, leeg
    • Op beide schijven LVM PV’s van ~450TB, tot 98% van de volledige ruimte
      • Bij sommige LVM-bewerkingen is een paar MB aan vrije ruimte nodig, er is nu 40G per schijf beschikbaar voor noodgevallen.

Schijven inrichten

Zoals beschreven, op iedere schijf partities van 450GB met (in fdisk) type 31 (Linux LVM):

# fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EFRX-68A
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 2DF239C2-BCE1-674A-ACCA-F6D6C45B5649

Device          Start        End   Sectors   Size Type
/dev/sdb1        2048  951757283 951755236 453.9G Linux LVM
/dev/sdb2   951758848 1903514564 951755717 453.9G Linux LVM
/dev/sdb3  1903515648 2855271850 951756203 453.9G Linux LVM
/dev/sdb4  2855272448 3807029134 951756687 453.9G Linux LVM

In de eerste instantie een enkele partitie aan een VG toekennen

# pvcreate /dev/sdb1
  Physical volume "/dev/sdb1" successfully created.
# vgcreate yunohost /dev/sdb1
  Volume group "yunohost" successfully created
# pvesm lvmscan
yunohost
snelsys
slowsys

Nu in de Proxmox GUI, via Datacenter –> Storage –> Add –> LVM

Het is verwarrend dat zowel ID als Volume group leeg en verplicht zijn. Bij ID geef je zelf een naam voor de Proxmox-storage op (yunohost, hier), bij Volume group kies je de LVM VG waar de opslagruimte in terechtkomt. Het resultaat:

ISO’s wil ik op een los volume zetten, maar Proxmox gebruikt LVM-volumes als block-storage; ISO’s moeten kunnen enkel op file-storage opgeslagen worden. Het voorbeeld voor directory-opslag laat zien dat de standaardlocatie /var/lib/vz is, daar staat nu een lijstje lege directories. Ik maak een LV met bestandssysteem, kopieer de data en koppel het op die locatie:

# ls -ls /var/lib/vz
total 20
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 dump
4 drwxr-xr-x 2 root root 4096 Dec  3 18:14 images
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 private
4 drwxr-xr-x 2 root root 4096 Jan  9 19:08 snippets
4 drwxr-xr-x 5 root root 4096 Jan  9 19:02 template
# lvcreate -n isosetc -L 4G slowsys
  Logical volume "isosetc" created.
# mkfs.ext4 /dev/mapper/slowsys-isosetc 
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 1048576 4k blocks and 262144 inodes
Filesystem UUID: 020be116-ab3f-474b-b407-a7301e59399c
Superblock backups stored on blocks: 
        32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done 

root@thuis:~# mount /dev/mapper/slowsys-isosetc /mnt/
root@thuis:~# cp -r /var/lib/vz/* /mnt/
# echo '/dev/mapper/slowsys-isosetc /var/lib/vz    ext4 defaults 0 2' >> /etc/fstab 
# touch /mnt/ok
# mount /var/lib/vz
# ls /var/lib/vz
dump  images  lost+found  ok  private  snippets  template
# 

Nu kan ik met de ingebouwde template-downloader templates van Proxmox ophalen, bijvoorbeeld Debian 10 (voor het screenshot opnieuw geopend; het template is al te zien in de achtergrond)


Op het samenvattingsscherm voor dit stukje opslag is te zien dat de hoeveelheid vrije ruimte en de hoeveelheid gebruikte ruimte schommelt. Tot het aankoppelen van het nieuwe volume bestonden de totale vrije ruimte en de gebruikte ruimte uit alles op LV var, aangekoppeld op /var. De vrije ruimte neemt toe van 3G (vrij op LV var) tot 4G (de vrije ruimte op LV isosetc). De gebruikte ruimte neemt af van ‘alles op /var, behalve /var/cache en /var/log’ (op hun eigen LV) naar 0, en daarna weer tot halverwege 500MB na het downloaden van het Debian-template.

Netwerk – bridge

Op de andere machine heb ik een Open vSwitch bridge gemaakt. Deze keer probeer ik het met een Linux bidge, die schijnt eenvoudiger te werken, ik gok dat dat minder resourceverbruik betekent.

De machine heeft twee fysieke netwerkpoorten, een er van is aangesoten (enp3s0). Via ‘Create –> Linux Bridge’ heb ik de bridge toegevoegd. Zowel de netwerkkaart zelf als de bridge heb ik op autostart gezet, bij enp3s0 was dat initieel niet actief. Het resultaat in de GUI:

De configuratie kan vanuit de GUI toegepast worden als ifupdown2 beschikbaar is. Vanuit de CLI ziet het resultaat eruit als:

root@thuis:~# apt install  ifupdown2
Reading package lists... Done
Building dependency tree       
...
dpkg: ifupdown: dependency problems, but removing anyway as you requested:
dpkg: ifenslave: dependency problems, but removing anyway as you requested:
Saved in /etc/network/interfaces.new for hot-apply or next reboot.
root@thuis:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual
# This is an autoconfigured IPv6 interface

iface enp2s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 192.168.168.6/24
        gateway 192.168.168.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
 kijken of dat zo werkt, moet later aangepast worden naar correcte IP's

iface vmbr0 inet6 static
        address 2001:985:b79a:1:225:90ff:fe33:1189/128
        gateway 2001:985:b79a:1::

root@thuis:~# 

Container toevoegen

Met de blauwe ‘Create CT’-knop voeg je een container toe. Hierboven heb ik aan de voorwaarden om er een aan te kunnen maken voldaan:

  • Template – er is een template beschikbaar

Screenshots van de installatiestappen (todo…):

Login

Inloggen zou makkelijk moeten gaan: IP via DHCP,de machinenaam heb ik opgegeven, moet via lokale DNS op naam bereikbaar zijn, SSH public key heb ik meegegeven, dus login met root@fakraz zou meteen moeten werken.

Niet dus. IP opzoeken in de GUI geeft geen resultaat, er staat alleen ‘DHCP’. In de router/dhcp-server staat onder het MAC adres van de container het IP van de host. Login via console en via shell in de GUI gaat op twee manieren mis: soms is er geen login-prompt, als hij er wel is dan wordt het wachtwoord niet herkend. Blijkbaar herinner ik me niet goed wat ik ingevuld heb.

Gelukkig kan ik vanuit de host toegang krijgen tot de container, met pct:

root@thuis:~# pct enter 100
root@fakraz:~# passwd
New password: 
Retype new password: 

Na een reboot van de container werkt ‘opeens’ de login via public key ook, maar de login via console blijft wisselend. Het wil wel eens een paar minuten duren voordat de login-prompt op het scerm staat, maar als die er eenmaal is, lukt het wel in te loggen.

Installatie Yunohost

Het kan allemaal niet in een keer goed gaan natuurlijk. Yunohost heeft last van een DDoS-aanval, waardoor https://install.yunohost.org niet beschikbaar is. Bij het ophalen van de pagina via web.archive.org kreeg ik een certificaat-fout. Google’s cache was wel beschikbaar, maar daar krijg ik 403, geen toegang, met wget.

Tekst kopieren en in een los installatiebestandje plakken lukt wel.

Bij het uitvoeren komen er veel locale-errors voorbij:

perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory                                                                     
locale: Cannot set LC_MESSAGES to default locale: No such file or directory                                                                  
locale: Cannot set LC_ALL to default locale: No such file or directory

In de container mag dpkg-reconfigure locales niet schrijven naar die locatie, gok ik, want toevoegen van de locale geeft in dpkg dezeldfe fout.

Daarom op de host de locale en_US.UTF-8 toegevoegd (naast en_IE.UTF-8); de installatie start nu en verloopt op de normale manier.

Klaar!

Daarmee draait alles:

  • Debian geinstalleerd
  • Proxmox op Debian geinstalleerd
  • Container met Debian op Proxmox
  • Yunohost op Debian in de container

Het draait, met weliswaar lage belasting op het moment, als een zonnetje. Qua hardware heeft Supermicro 2U Twin3 2015TA-HTRF 8x precies deze configuratie. Op hoofdlijnen:

  • Supermicro X7SPA-H-D525
  • Atom D525, 2 cores / 4 threads@1.8GHz
  • 4GB RAM
  • 80GB SSD
  • 3x 2TB HDD

Print this entry