In part 1 we set up the very most basic dovecot install we could get away with. In this part we will try to redeem it a bit by improving the security of the the authentication mechanism and the storage of passwords on the server. In other words we will make it much harder to snoop on our communications with the imap server and decrease the overall likelihood of somebody learning our password, including anybody with access – legitimate or otherwise – to our server.
Category: Server
Let’s do Dovecot slowly and properly – Part 1: PLAIN as day
This post follows up on the fifth installment in my Let’s do Postfix series. We’re not really done setting up Postfix but a) it’s about time we had a better way of accessing incoming mail than ssh’ing into our server and using cat to read and b) we are at a juncture where the two will soon start depending on (SASL) and interacting with (LMTP) each other
This tutorial presumes knowledge of Postfix and the setup we’re aiming for is one that complements the Postfix one that we’ve set up in previous installments. As with the Postfix series I want to arrive at a working setup from the very first post but knowing full well that it’s not an ideal or final setup. The advantage (over importing somebody else’s full featured setup) is that we’ll actually understand what we have on our hands (and it’s shortcomings). This makes it a lot easier to build and improve upon it and fix it should the need arises.
A note on safety: The setup we’ll end up with today is not going to be confidential in any way, shape, or form. It will expose both the contents of the account’s emails and whatever password you choose to the entire internet. Therefore you should obviously use either a test account or a brand new one that has nothing important on it yet. As for passwords you should pick one for testing that you have not used nor intend to use for any non-testing purposes. That said, un-confidential is not the same as unsafe. Any public facing service is a potential attack vector but this setup is – to the best of my knowledge – no more of one than a more properly confidential setup.
Setting up Postfix and Dovecot Slowly and Properly
Back in 2015 I embarked on an ambitious plan to blog my entire way through setting up my own selfhosted email server. I got a fair bit in (5 posts) before the setting up got ahead of the blogging and I lost track of scribbled notes and halfwritten posts. Moving to a fresh Ubuntu 18.04 install I decided to move as many services as possible to containers, including my email setup and so, rather than just copy paste my old config files I dug into the basics of email setup again.
Homeserver: NUC vs Raspberry Pi
I have tried at various points to write a followup to my “so what’s it like using a NUC for a homeserver/HTPC?” post. Mostly it strands on there not really being anything new to add. It works. The added workload of more applications (and maybe more traffic?) over the past two years has made it run a bit warmer and louder than it used to despite being de-dusted a couple of times. But it’s still doing it’s job. I have thrown in some docker containers and they work just fine. Run a virtual machine with kvm? Sure. As of now the main threat to it’s immortality is it’s inability to transmit 4K over HDMI. Not that I’m about to buy a 4k TV but some day, yeah?
The main thing that has kept me wondering if it is the right pick is the question: Did I splunge needlessly? Could I have gone for something cheaper without sacrificing anything? Specifically: Could a Raspberry Pi have done the job just as well?
I picked a Raspberry Pi 3 up at the post office on monday so I should finally be able to get an answer. I’m not replacing my own machine; my dad need a new home server after his Atom-powered fit-pc2 gave up the ghost. I quizzed him about his needs and found that they were fairly basic: A ‘LEP’ web server (Linux, Nginx, PHP, no MySQL) and for HTPC purposes access to the national broadcaster whether through browser or a Kodi plugin would suffice. This, I thought, had to be a good test case for picking a Pi over a full x86-based machine.
Chorus2 + Firefox 51 = Easier music streaming
One of many new features in Kodi 17 is the new default web frontend, Chorus2. The old Kodi frontend was an extremely basic web remote that allowed you to start, pause and select media. Chorus2 does all that in much slicker package AND has a ‘local’ tab for local playback, i.e. streaming from the Kodi instance to whatever device you’re controlling it from.
Running Kodi as a pure client on linux
When I got rid of the last Windows partition on any of my home computers, I thought I would finally give NFS a chance to replace CIFS as the reigning network file system in my house. To it’s credit, NFS took that chance and ran with it and it’s worked pretty much flawlessly ever since. Seeing how reliable it has been, it has become my primary means of accessing media located on my HTPC when not in front of/within earshot of the my TV/hifi but still on the local network.
That approach, however, has some serious shortcomings. I can’t see what I have and have not watched. I can’t see if I’m halfway through a movie – something that is depressingly common in this ADD world of media abundance. I have to move between file managers and video players, something that isn’t that practical when my 2-in-1 laptop is in a position that hides away the keyboard and I have to rely on the touch screen. And I find myself missing the inviting presentation of Kodi from my HTPC.
So recently the thought struck me: Could I not just set up a second Kodi instance on my linux laptop only as a client? Turn a full-fledged Kodi application into a dumb terminal? An… *makes sign of the cross* ‘app’? Only then I did I remember that, wait, wasn’t that sort of the selling point of Plex over Kodi? Apps aplenty? Streaming everywhere and anywhere? Well, yes. But it can be done with Kodi. Sort of. Here’s what I got.