I have been fighting for years with smartd but I really never managed to configure it the way I want. While I certainly am not backblaze, I still have quite a few hard disks I would like to monitor and be able to replace before they actually die. I hacked up a small Python script to query some SMART attributes and send me an email in case something funky is going on; to use it just put in /etc/cron.daily and tell cronie to run it. To work correctly the script also needs smartctl and sendmail. …

This does not really works, read this: https://uwot.eu/monitor-hard-disk-smart-status-in-python/ First of all install smartmontools, it has the same name on pretty much every distro: $ emerge -a1 smartmontools Proceed to edit its configuration file, at the bottom of the file there is a quick explaination of all the available parameters: cat/etc/smartd.conf --- DEVICESCAN -H -R 1 -R 5 -R 7 -R 10 -R 11 -R 196 -R 197 -R 199 -R 200 -m user@domain.tld -n standby,10,q Parameter -H tells smartd to check the result of overall-health self-assesment test which is pretty much useless, -R is used to specify a single SMART attribute, if its value changes a mail is sent to user@domain.tld. To send emails a MTA must be installed, in centos that is sendmail, in gentoo it is not strictly necessary to have a full fledget MTA installed, nullmailer will suffice. If it is not already installed: …

Android community is one big cancerous clusterfuck, it is no wonder that finding a decent guide on how to compile Android from source written in a somewhat comprehensible english is pretty much mission impossible. Cyanogenmod Inc. shutting down their wiki and services overnight surely didn’t help either. Required packages on Fedora 25 are (rpmfusion repo must be previously installed): $ sudo dnf install screen java-1.8.0-openjdk-devel git schedtool ncurses-devel ncurses-libs ncurses-compat-libs ImageMagick-devel libstdc++-devel bison gnupg lzma For some reason the compilation process stores some temporary files in /tmp which, in Fedora 25, is mounted on a tmpfs ramdisk. In case the ramdisk runs out of space for some retarded reason the build process instead of halting will go on like nothing happens and produce borked binaries as output. To keep /tmp mounted on HDD run: …

Android stores application’s data in /data/data directory, it can be accessed via adb only on a rooted phone. To make a backup copy the correspondent directory: $ adb root $ adb pull /data/data/eu.siacs.conversations Application’s data can also be extracted from a full system backup made with TWRP: $ tar -xvf data.ext4.win000 Restoring the backup is the tricky part since Android uses SELinux and every app has it’s own unix user. Before copying back on the phone the already backupped files reinstall the app from f-droid or whatever, then proceed as follow: …

Btrfs is fairly stable and with the latest kernels it is becoming even a better alternative to the most commonly used EXT4 and XFS filesystems. While not being always better or faster it brings to the table a huge amount of improvements that makes it by far the best filesystems for storage. XFS itself is moving in the very same direction and will probably have in the near future some of the features Btrfs already has (e.g. copy on write). No MDADM or partitioning is needed, to create a RAID10 with 4 HDD just type (where /dev/sd[X] is the disk whole disk, not a partition): …

XMPP module HTTP File Upload (formerly XEP-0363) provides a way to share files between XMPP clients, it works transparently and even in multi user chats. The sender uploads a file on an HTTP(S) server that will then generate an URI, this is sent to each one of the recipients that can then download it. The interesting bits about this XEP are various: File sharing now works even in multi-user chats (MUC), in any case the file is only uploaded a single time even if the recipients are more than one. Peer-to-peer file transfer, be it in-band (XEP-0234: Jingle File Transfer) or out-of-band (XEP-0065: SOCKS5 Bytestreams), is slow, unreliable, does not work in MUC and does not work if the recipient is offline. HTTP File Upload supports both client-server encryption (HTTPS) and end-to-end encryption when used in conjunction with OMEMO encryption (as per today this is supported by Conversations on Android and Gajim desktop client). 3.1. When using OMEMO encryption the files are stored encrypted on the server, this makes it impossibile for ejabberd to create a thumbnail if the file sent is a picture. To enable HTTP File Upload module with HTTPS enabled in ejabberd edit ejabberd.yml configuration file: > listen: - port: 5443 ip: "0.0.0.0" module: ejabberd_http request_handlers: "upload": mod_http_upload tls: true protocol_options: 'TLS_OPTIONS' dhfile: 'DH_FILE' ciphers: 'TLS_CIPHERS' modules: mod_http_upload: docroot: "/home/ejabberd/upload" # this must be a valid path, user ownership and SELinux flags must be set accordingly put_url: "https://@HOST@:5443/upload" access: local max_size: 25000000 #25 MByte thumbnail: false file_mode: "0644" dir_mode: "0744" mod_http_upload_quota: max_days: 2 shaper: soft_upload_quota: - 250: all # MiB hard_upload_quota: - 10000: all # MiB define_macro: 'TLS_CIPHERS': "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256" 'TLS_OPTIONS': - "no_sslv2, no_sslv3, no_tlsv1" - "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256" - "no_compression" 'DH_FILE': "/usr/local/etc/ejabberd/dhparams.pem" # generated with: openssl dhparam -out dhparams.pem 4096 Add an iptables rule to allow traffic coming from port TCP 5443: …

Sparse files are nice to use to store virtual machine’s virtual disks but can be a real pain in the ass to backup efficiently, especially over the network. Luckily rsync provides a way to intelligently copy sparse files both locally and over the network. The trick is use --sparse and --inplace options. Let’s say we have a sparse 60 GB qemu virtual disk with only around 7 GB used: $ ls -lh fedora24.qcow2 -rw------- 1 root root 61G Nov 8 19:11 fedora24.qcow2 $ du -h fedora24.qcow2 7.2G fedora24.qcow2 The first thing to note is that ls does not recognize sparse files while du does. The first time a file is copied use the --sparse option: …

All Cyanogenmod 13 nightly builds past July 28 seem to be affected by a bug that makes the phone reboot just a few seconds after opening the Gallery application. The issue seems to be related to the newly added support to sdcardfs which obviously isn’t playing well at the moment. A workaround to prevent the phone from crashing and rebooting is to edit the build.prop file located in /system; this can be done either via adb using the command adb shell or more practically directly on the phone using the built in file manager and text editor (provided that in file manager’s settings access mode option is set to Root access mode). …