YetI

Yeah… sorry about that… The long-awaited change of server that I had been planning for more than a year has finally happened :-) It took some time, and things are coming back online one piece at a time…

On the good side, Git has become easier to browse and use. See here: https://yalis.fr/git/

Three years ago, I wrote a small series about having all my favourite tools on a USB flash drive when I am on the go. Some things have changed in these years, so the time has come to write fresh blog posts on the subject. My main aim is a full portable Linux OS, and this third part is about just that!

This is a new take on my 3-year-old series on the same subject, with the aim of having a portable toolbox for anything PC, from booting Linux, to having my favourite productivity tools at all time, to being able to rescue a broken disk or OS, and so on. This toolbox takes the form of a standard USB flash drive, made bootable and filled with all that I need, yet still uncluttered, and usable as any USB flash drive for transferring data.

This first article is about the “bootable” part.

Le Fairphone 2 est un excellent téléphone. Je ne savais trop comment présenter cette acquisition…

Quelqu’un l’a déjà fait, bien mieux que je ne saurais le faire. Allez-y, c’est très bien écrit :

https://grisebouille.net/fairphone-un-telephone-pour-libriste/

A bit more than a year ago, I hardened my SSH server, which resulted in the near-disappearance of automated SSH login attempts. Alas, the script-kiddie tools have finally caught up with the current state of cryptography; or at least with the level of cryptography that I dare require, and still maintain compatibility with most devices that I use.

Fail2ban, although dormant all this time, still ran like the ever-vigilant Argos, and resumed its usual work as the attacks came back. But I do not like relying solely on fail2ban. So I decided to add port-knocking as a protection.

I am very fortunate that one jflesch on GitHub decided one day to create Paperwork! This excellent program evolved very quickly and is still improving. I manage all my official documents, invoices, and such, in Paperwork. Scan by scan, PDF import by PDF import, I am slowly approaching the 2000 documents, or 5000 pages. This program has proved invaluable in the past year alone, both for speeding up the processing of new documents, and for looking for old documents.

Yet I miss one feature: the possibility to search the database of documents (which is on my home server) from any computer or mobile device, without having to launch Paperwork, which is only installed on the main family PC.

Besides, as I often connect to my server from distant places using OpenSSH, the possibility to do command-line searches would be a big improvement over my current use of find, grep, etc. Or I should rather say, my former use of find, grep, etc. Because…

J’ai recommencé à tenir mes comptes dans l’excellent GnuCash. Comme je n’ai pas le temps (ni l’envie) de tout saisir pour ensuite rapprocher les comptes, j’importe les données depuis les fichiers téléchargés sur Internet et je me contente d’affecter les revenus et dépenses, et vérifier que tout est normal.

Mais tous les organismes ne fournissent pas de fichiers directement exploitables. Beaucoup se contentent de fichiers PDF…

I recently began using ownCloud for file synchronization. All in all, although there are some minor hindrances, the experience is really satisfying. So much so, that I moved all my “personal cloud” data to ownCloud, from the previous NFS share. However, although the regular ownCloud client is just fine where available, it is not available everywhere. In particular:

• I carry around on a USB stick a lightweight Linux desktop based on TinyCore Linux, for which the client is not available.
• I also have an old laptop that is stuck with an obsolete operating system because the video chipset is buggy, and no newer OS will support it (even though the “same” chipset reference in another laptop works just fine…).

For these situations, I tried using DavFS, but this solution was much too slow; it is a great fall-back, though. Next I tried the Java program WebDAV-Sync, but although the initial download went fine, sync did not work all that well: the whole share was fully downloaded again each time!

So I created my own synchronization tool, the only dependencies of which are curl and bash, and optionally ssh. These dependencies are available everywhere, including Windows and some embedded systems ;-)

Cet article a été traduit en français.

My personal server only served a few real users to this day, which means that each of us had an account on the server, that owned files and could run commands, schedule tasks, and so on.

I just extended my hosting perimeter, but I only allow email usage for my new guests so far. With this in mind, I did not want to create new Linux accounts, which would have needlessly weakened my server by exposing it to attacks towards these new accounts. Thus I created my first virtual users, for electronic mail.

I found several configuration examples on the Internet, but those mostly addressed situations where all users were virtual, often in several domains, or where a given domain was targeted at real users while others domains were targeted at virtual users. My wish was rather to allow new, virtual, users into my existing domains, the users of which were so far of the real kind only. Still, by taking from all those readings, it was not that hard to get there.

Cet article existe aussi en français.

With the new Debian Jessie, I found that my PHP pages would all be displayed as blank pages, even though all regular HTML pages would display correctly.

This comes from the fact that the SCRIPT_FILENAME parameter has been removed from the /etc/nginx/fastcgi_params file. A new file, named /etc/nginx/fastcgi.conf, does reintroduce this parameter, but with the official value “$document_root$fastcgi_script_name”, instead of the former value “$request_filename”.

I really do not understand why the new value is the official one upstream, since it does not play well with aliases. So, first, I referenced fastcgi.conf instead of fastcgi_params, since the former seems to be the preferred file now ; and second, I changed my Nginx configuration to define SCRIPT_FILENAME this way:

fastcgi_param SCRIPT_FILENAME $request_filename;