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.
Category: Server
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.
Get up on my cloud: What to consider when choosing private cloud software applications
Getting off of the corporation cloud and onto your own, self-hosted, open source-based is an arduous task. We use a lot of web based services these days and replacing each and every of them, one by one, requires some forethought so that you don’t move all your data over to something that simply does not work for you.
I have currently setup some 10+ web applications on my private cloud. I could make a list of them and explain why they’re the best available in their respective categories but I think it would be more helpful to suggest some guidelines when looking for your next selfhosted web application.
They finally let us: Trying out the Let’s Encrypt beta
“Greetings from Let’s Encrypt, mail@brokkr.net.”
Greetings to you too. It’s been quite a wait so I guess a bit of formality is in order. Now, can we please stop saying “Let’s” and just encrypt already?
Let’s do Postfix again but slowly and properly this time – Part 5: Relaying from the local network
When running your own SMTP the real spam challenge is to avoid getting used by spammers. It is not to avoid getting targetted by spammers. Mind you, you don’t want spam in your inbox but a) that’s what filters are for and b) spammers (mostly) use confirmed lists of recipients, they don’t probe domains for addresses. When they do probe, they probe for access to relay, to use your server to distribute their junk. If they’re successful you’ll have far bigger problems than having to delete a couple emails a day (i.e. your IP and domain winding up on blacklists; also your ISP may disapprove).
That is the reason I have saved relaying until now. Opening yourself up to reciving unwanted mail is at lot less problematic than opening yourself up to having your server hijacked by spammers. Postfix is by default set to be rather restrictive in who it lets send out mail so while we have been messing about with receiving mail, the mail sending settings have stayed default and safe.
This will be a short post, as we will only get to know how to relay mail based on the mynetworks setting. ‘Relay’ is fairly synonynous with ‘sending’ but AFAICT it only refers to sending between SMTP servers. A user sends an email. An SMTP server relays it to another SMTP server. This post is about relaying from a local network.
Let’s do Postfix again but slowly and properly this time – Part 4: Virtual domains
To revisit what I said in the first post in our Postfix series, a virtual setup is one in which email accounts are independent of system accounts. We therefore have to tell Postfix what accounts we have on any given domain, where to put email for an account etc. unlike local delivery where users are given by the system and delivery is by default to a file in /var/mail. In order to create this kind of setup we will have to jettison most of the settings we have worked on so far. On the plus side it will still feel very familiar as settings are often in parallel. And you’ll understand how to properly distinguish between the two kinds of setup.
From the outside there will be no discernible difference. Our Postfix server will accept mail for users on legitimate domains and reject mail for all other destination.