OK - so I’ve spent the whole morning (apart from the bit where I mowed the front lawn and whippersnipped bits of it) working on this :
Automatically send me an email each week - on Wednesday arvo / evening about which bin(s) to put out for collection the following day (Thursday) - e.g. Red for General Waste, Yellow for recyclables - FOGO (i.e. rotting organic matter ) just goes out every week - regardless…
Got most of the algorithm stored in my head… The crontab bit’s easy - just do it every “WED” :
15 16 * * WED /home/x/bin/whichbin.bash 2>&1
Sorted that bit… created a space separated table / array :
... 23 6 1 RED 23 6 8 YEL 23 6 15 RED 23 6 22 YEL 23 6 29 RED ...
YY m d $COL
I might put in a 5th column (sic ) of the day before, i.e. “TODAY” of the day it runs… But I think there’s some fancy-schmancy English like regex you can do with date’s these days, e.g. find out what tomorrow’s date is going to be…
date --date='tomorrow' ‘+%d’
╭─x@titan ~/sbin ╰─➤ date --date='tomorrow' '+%d' 13
RED = General waste
YEL = recycling (aluminium, paper, glass etc)
So I get to the bit where I have to setup mailing via one of my gmail accounts (I have several) - and - I’ve actually done this before many years ago (I’d email myself if my home internet connection changed external IP Address). But Google have changed EVERYTHING and you now have to configure your google account to allow “Apps”.
So - I figured that out - and tested, I can send emails from my main Linux desktop machine (Pop!_OS 22.04), to my gmail inbox! Woohoo! That worked! Using package ssmtp (“sudo apt install ssmtp”).
But this is a test case… Ideally I want to run this on my Pi4 running buster as I know it’s on all the time, and it’s wired directly via UTP into a gigabit port on my WiFi/Router…
╭─x@beere253 ~/bin ‹main*› ╰─➤ sudo apt install ssmtp Reading package lists... Done Building dependency tree Reading state information... Done Package ssmtp is not available, but is referred to by another package. This may mean that the package is missing, has been obsoleted, or is only available from another source E: Package 'ssmtp' has no installation candidate
Really? Lotsa BIG SWEARY WORDS!
And the READMEs and forums are all saying don’t use ssmtp it’s deprecated or no longer maintained (I really couldn’t give a rat’s - as long as it works and it DOES work with all the 2FA shit that google force these days) - BUT - HUGE BUT - Canonical, and System76 let it stay! IT works! The forums etc cetera are all saying use “msmtp” instead…
BUT THE CONFIGURATION for that package is completely different.
You know what? I AM SERIOUSLY contemplating wiping Debian Buster (Raspbian) arm64 off it and going with Ubuntu server 22.04 for arm64… Shock horror! Replace Debian with Ubuntu? Why NOT? Works for me… I can even test it first - I have a spare Pi4… and a Pi3!
Some of my answers might be here :
But you know what? I REALLY kinda HATE it when the answer’s “compile it yourself…”
At least this answer builds a DEB I can install later - or even save on my NAS…
Jeepers! Buster’s EOL already! Seems like we just got it…
Extra reason to go for an LTS Ubuntu… But first I’ll try and get ssmtp working on buster… Damn! I’m still running Stretch on my TVHeadend Pi3!
I’m just going to test if Ubuntu 22.04 server arm64 supports ssmtp (or has the package) with a VM on my MacBook (I use UTM to manage VM’s on Mac - and I can do native arm64 virtualization).
Spinoza was a great thinker - but the owner / writer at espinoza.tv hasn’t “future proofed” his guide - so maybe not such a great thinker? - as - ssmtp_2.64.9 does NOT exist… in fact - that URL hosts arm64 binary deb installers - but NOT any of 2.64.9 (not binary DEB or source) - I can’t install 2.64.10 'cause unmet dependancies (libgnutls-openssl27 is too old), and there’s a 2.64.8-+b (beta I assume) that dpkg installs - but DOES NOT CREATE ANY F–KING BINARIES!
ssmtp binary is supposed to go in /sbin/… that’s where it goes on Pop!_OS 22.04 - one would assume Ubuntu 22.04 does the same thing… Just about to test on Ubuntu 22.04 arm64 (had to do-release-upgrade a clone of a ubuntu 20 arm64 vm in UTM)…
Debian Buster DEB installer of ssmtp 2.64-8beta installs to /usr/sbin/ssmtp - which just happens to NOT be on my path!
Going to run two Pi4 off gigabit ethernet off my Router in “parallel” while I cutover to Ubuntu 22.04 Server arm64… Once all’s good, I’ll just switch 512 GB USB 3 SSDs around so my 4 GB headless Pi now boots off the other SSD I setup with an 8 GB Pi4… Too easy…
Within 10 minutes of my Pi4 with Jammy Jellyfish (22.04.2) being up and updated - I’ve now successfully tested ssmtp (sent an email to myself) - so soon it shall be GOODBYE to Raspbian / Debian / Buster… I’ll still have Stretch running my TVHeadend setup, and bullseye on my Pi Zero 2W… but that’s it…
- armbian 16 (ubuntu 16 - headless) 32 bit arm on Orange Pi+ 2E 2GB RAM (transmission-daemon server)
- raspbian stretch 32 bit armhf on Pi3
- raspbian bullseye 32 bit armhf on Pi Zero 2W (arm64 bit capable)
- red hat EL 8 on a Gigabyte Brix (2 celeron cores, 16 GB RAM 512 m2 SATA SSD) - x86_64
- Pop!_OS 22.04 - Ryzen 7 desktop - x86_64
- Pop!_OS 22.04 - Ryzen 5 Thinkpad - x86_64
- Pop!_OS 22.04 - Raspberry Pi4B (8 GB) arm64
- MacOS Monterey 12.61 - MBP M1 - 16 GB RAM 512 GB SSD (arm64)
- MacOS Monterey 12.61 - MBP M1 - 8 GB RAM 256 GB SSD (arm64)
- FreeBSD 12.2 (TrueNAS 12) - 16 GB ECC RAM 256 GB SSD 4x4TB RAIDZ+1 (amd64)
I don’t actually >>need<< “need” my old Raspbian Buster Pi4 instance… I reckon I’m going to cutover this evening… i.e. just swap SSD’s - too easy… I’m WFH tomorrow and Tuesday, and I NEVER go into the office on Wednesdays, so I got bucketloads of time to get this sorted… and I can always resort to looking at the old SSD from my Pop!_OS thinkpad (the desktop machine is having issues with some USB3 stuff - but annoyingly, not EVERYTHING).
It will be a shame, my old Buster system has 197 days uptime! I HATE breaking reliable long term uptimes! But it’s goodbye methinks… adieu mon cherie!
(there’s a machine at one customer - that only I use, which has 6-7 years uptime - and I DO NOT WANT to disturb that kinda rock solid stability [CentOS])