updating aur packages with yaourt
Wednesday, December 6. 2017
This is a work in progress for right now I dont seem to know how to do it right.
sudo yaourt -Syu --aur
searches through my system and upgrades the db and then presents me a list of aur packages that need upgrade and then it works it's way through the list and I need to stay there and check every dialog and when there is a package I do not wish to upgrade I cannot skip it. Sure, there is a dialog asking me if I want to update this package, but if I give it a "no" the entire routine is aborted.
So, in case the package I really want to update happens to be the last in yaourt's list I have to update all of them, including the huge font collection which takes ages to download and build, and including the printer driver which I'd rather not touch at all.
That got me shouting and cursing yesterday cause following the update of the driver for the Brother QL-710w label printer the darn thing wouldnt print any more. CUPS was happy though, preparing the print data, posting them to /var/spool/cups and instantly flag it for completed, no errors.
The package that gave me trouble is aur.archlinux.org/packages/brother-ql710w/ with the version 1.1.4r0. The prior version, pkgver=1.0.2r0 had installed and worked like a charm.
I spent hours trying to find a reason ar even a hint t what was failing to work but nothing helped until I decided to downgrade to the original version.
Now, with 'official' arch packages this is rather esy, there is a storage of older versions at /var/cache/pacman/pkg and you can take the package from there and downgrade with a pacman -U packageName
But packages from aur are built when you install them, in /tmp and so they are usually lost when you try to step back. I have learned now that there is an option to change this in the /etc/yaourtrc config file. Next time it will be easier.. But as things were I chose a different path yesterday, I manually downgraded the package when it offers me to edit the build script. Changing the pkgver and the sha256sums was all it took.
One of the things I discovered was a nice feature of the aur git, in my case the url is https://aur.archlinux.org/cgit/aur.git/?h=brother-ql710w
I clicked around and soon had the site show me diffs of the prior and new version. Clearly the package was not at fault for my problems. Or Brother has changed some requirement for the install which the former version did not need and which should be reflected in the new package version - I didn't investigate this.
What I did is, searching on the Brother support site for links to older versions of the driver (none!) and then play around with the new url until I succeeded to get the old versions. Naming conventions are a good thing. Then, after successfully downloading them I took their sha256sums
sha256sum ql710wcupswrapper-1.0.2-0.i386.rpm
and those I pasted into the build script. After hours of fruitless trying I was perplexed to see it work on the first go.
That step wasn't actually necessary, I could have taken the sums from the diff at aur.archlinux.org/cgit/aur.git/diff/PKGBUILD
FireFox Sync Server
Thursday, November 30. 2017
After years of Chromium as my default browser I've moved to give FF a new go after the release of v57 aka Quantum. Mozilla is still more trustworthy than Google and hey, I prefered Netscape over Mosaic once. Part of the shift was trying out FireFox sync. Since I have not much trust in the cloud unless it is my own server this meant installing Firefox Syncserver on my debian server.
I more or less followed the howto from sathya.de/blog/how-tos/setup-your-own-firefox-1-5-sync-server-on-debian-with-apache2-and-mysql/ , there are links to the mozilla docu included on his site. The basic steps are easy to take, with dns.he.net and letsencrypt with dehydrated setup of a new subdomain with a valid SSL-certificate has gone down to a matter of minutes.
Git clone the server, create a db and db-user, config the virtualhost in the web servers configuration, edit the default syncserver.ini, restart the webserver and then tell the clients in about:config which syncserver to use. Pretty basic, but it still has some potential for confusion and took me two runs to get it running.
the supplied syncserver.ini has an entry public_url = http://localhost:5000/ which appears to suggest that ports should be defined in the server config, client config. But this is not so, in a production environment with https and a web server non ports are given.
I saw 404 errors in the error_log which stemmed from an error with the client config, I had erased the token/ - ppart of the uri. And I experienced a multitude of 500 server errors with traces in the error_log pointing at a line between Public_url = ... and allow_new_users = ...
The first complained the given secret exceeded the maximum length, while it had been created like the comments advise. Later I saw errors from parsing the sqluri. Many visual checks did not find a problem.
What helped me was a set of voodoo measures including: manually retyping the sqluri line and inserting a 'dummy = stupid' line supposed to catch any non-visible carried syntactical elements. Other possible sources of problems here include permissions issues and missing execution flag on the wsgi file.
And then, suddenly, it worked.
Install and config of Collabora with nextcloud on debian with apache2 without Docker.
Thursday, November 16. 2017
Debian 9.2
# Encoded slashes need to be allowed
AllowEncodedSlashes NoDecode
# Container uses a unique non-signed certificate
SSLProxyEngine On
SSLProxyVerify None
SSLProxyCheckPeerCN Off
SSLProxyCheckPeerName Off
# keep the host
ProxyPreserveHost On
# static html, js, images, etc. served from loolwsd
# loleaflet is the client part of LibreOffice Online
ProxyPass /loleaflet https://127.0.0.1:9980/loleaflet retry=0
ProxyPassReverse /loleaflet https://127.0.0.1:9980/loleaflet/
# WOPI discovery URL
ProxyPass /hosting/discovery https://127.0.0.1:9980/hosting/discovery retry=0
ProxyPassReverse /hosting/discovery https://127.0.0.1:9980/hosting/discovery/
# Main websocket
ProxyPassMatch "/lool/(.*)/ws$" wss://127.0.0.1:9980/lool/$1/ws nocanon
# Admin Console websocket
ProxyPass /lool/adminws wss://127.0.0.1:9980/lool/adminws
# Download as, Fullscreen presentation and Image upload operations
ProxyPass /lool https://127.0.0.1:9980/lool
ProxyPassReverse /lool https://127.0.0.1:9980/lool/
Zertifikate von Let's Encrypt mit dehydrated
Friday, April 14. 2017
Mit dem jüngsten Update auf Chromium 57 funktionierten alle meine Zertifikate nicht mehr. Wosign und Startcom waren ja vor einer Weile in Ungnade gefallen und neu ausgegebene Zertifikate dieser Certification Authority (eigentlich ist es nur eine) wurden nicht mehr anerkannt, aber mit Version 57 hat Chromium/Chrome dies stillschweigend weiter eingeschränkt: jetzt sind auch ältere certs betroffen, wenn die Site nicht eine ganz Grosse ist und in Alexa top 1 Mio gelistet wird.
Könnte man sich darüber aufregen, hilft aber nicht. Die billigsten kommerziellen Zertifikate kosten 8 USD/Jahr und kommen von Symantec, was auch nicht gerade sehr vertrauenswürdig klingt.
Bleibt Let's encrypt. Das hatte ich bislang gemieden, weil die Laufzeit mit 90 Tagen zu kurz ist, um manuell Zertifikate anzufordern, der Client aber etwas monstroes daherkommt, zig dependencies hat, den Server selbst konfigurieren möchte und was nicht. Und es eilte ja nicht so sehr - jetzt aber.
Nach etwas Recherche fand ich mir einen schlanken bash-Client und bin zu meiner Verwunderung damit recht zügig zum Ziel gekommen.
- download von https://github.com/lukas2511/dehydrated/archive/master.zip
und entpacken nach /usr/local/bin
- in /etc/apache2/conf-available
eine datei dehydrated.conf
anlegen mit
Alias /.well-known/acme-challenge /var/www/dehydrated
<Directory /var/www/dehydrated>
Options None
AllowOverride None
# Apache 2.4
<IfModule mod_authz_core.c>
Require all granted
</IfModule>
</Directory>
und diese nach /etc/apache2/conf-enabled
symlinken
- in /var/www ein Verzeichnis dehydrated anlegen
- apache restarten
- in /etc/dehydrated
config und domains.txt aus dem docs - folder des entzippten Codes einkopieren, anpassen, dabei anfangs die staging-URL eintragen
- im Programmordner mit ./dehydrated -c
script aufrufen, ggf. Fehler korrigieren. Wenn es durchläuft, die staging-Urls auskommentieren und die certs bauen.
- in /etc/apache2/sites-available
die conf der vhots so anpassen, dass die neuen certs verwandt werden
SSLCertificateFile /etc/dehydrated/certs/beispiel.de/cert.pem
SSLCertificateKeyFile /etc/dehydrated/certs/beispiel.de/privkey.pem
SSLCertificateChainFile /etc/dehydrated/certs/beispiel.de/chain.pem
-apache restarten und fertig.
Cool, jetzt noch ein cron job, der das mit langem Abstand immer mal ausführt (und veraltende Zertifikate erneuert) und man kann die Sache vergessen.
Brother ql-710w und angepasste Etikettengrößen
Friday, November 11. 2016
Zum Labeldrucker ql-710w (und einigen anderen) gibt Brother ein Kommandozeilentool,
mit dem man Custom pagesizes, also eigene Label-Formate erstellen und einbinden kann.
Das händisch zu versuchen, endet leicht in rot blinkender Drucker-LED.
brpapertoollpr_ql710w -P ql-710w -n 62x35Label -w 62 -h 35
ist die Syntax, um ein neues Format 62x35Label mit Breite 62mm, Höhe 35mm
zu erstellen.
Das Tool geht aber ungefragt davon aus, dass
in /etc/cups/ppd die Datei ql-710w.ppd existiert und gibt sonst nur
lakonisch ein File not Found zurück.
mit
strace -ff -e stat64 -e open brpapertoollpr_ql710w -P ql-710w -n 62x35Label -w 62 -h 35
kann man sich das vor Augen führen.
Hier gab es halt nur eine anders benamte .ppd, deshalb einiges Herumsuchen und -kopieren.
andere hier nennenswerte Orte:
/usr/share/cups/model
/opt/brother/PTouch/ql710w/inf
Was eben leider nicht geht, obwohl man es erwartet (und andere
Betriebssysteme auch Druckertreiber haben, die das unterstützen):
Das das Ding von seinem Endlospapier einfach druckt, bis es fertig ist, und
dann abschneidet.
Diese Erfahrung mache ich nicht allein, Tante Guggel findet reichlich ähnliche Fragen.
Hilfreich waren mir Brother PCLinux-Forum Suse-Forum (mit Hinweisen auf einen besseren Foomatic-Treiber), natürlich das Arch-Drucker-Wiki
Diese Einrichtung hat mich fast 3 m Etiketten gekostet.
Davon ab ist das ein für seine Zwecke nettes Druckerchen mit ordentlichem Druckbild. Ich bin im Zweifel, ob es grosse Unterschiede zwischen dem Druckwerk des QL-700 und günstigeren Modellen wie dem QL-570 gibt, lt. Datenblatt hat der QL-7XX zwar bis zu 300x600 px Auflösung, aber die Treiberdialoge kennen nur 300px und auch ein anhakbarer Schönschreibmodus hat keine sichtlichen Unterschiede gemacht. Zur Ersteinrichtung des Wlan musste ich auf einem anderen Betriebssystem einmal die Software installieren und eine USB-Verbindung herstellen, ganz ohne Mac oder Win geht es nur, wenn man an seinem AccessPoint die 1-Klick-Anmeldung mit WPS unterstützt.