Major Hayden

I am working on a similar project. I have something working for my own needs and a few other families already but a long road to go before making something GA.

You can waitlist at https://havenphone.com if you are interested.

There were three major things I wanted to do differently from Tin Can:

- I wanted to use off the shelf VOIP hardware so if the company ever went out of business I (and any of my users) had an escape valve or could just sell the hardware.

- I wanted to have a code base I could open source. (not open source, yet!)

- I wanted flexibility to offer ATAs (devices that let you connect any ol' "analog" phone)- some of my parent friends wanted cordless "DACT" phones, interestingly.

It has been quite an adventure entering the world of VOIP.

The SIP protocol has so many esoteric options (understandably given its history!) it could make TLS look simple.

My most recent learning is this crazy protocol called TR-069 that ISPs use to configure endpoint hardware like home routers, cable modems, and VOIP phones. https://en.wikipedia.org/wiki/TR-069

Also, interestingly every cheap (sub-$50) phone and ATA I have tried has a built-in OpenVPN clients.

Oh, and one more interesting thing Grandstream ATAs are able to be taken over by the Grandstream cloud service by just providing the ATA serial number and mac address on the back of the device- I did not love that workflow when considering long-term security. (:

If you have $50 and some time to kill you can do it all…

> Instead of replacing them, systemd could have provided optional or mandatory services (eg time, dhcp, etc) that could be passed into systemd

If sntp is not sufficient for your needs, just disable systemd own sntp solution (systemctl disable...) and use chrony (systemctl start / systemctl enable to make it persistent): then `systemctl status systemd-timesyncd.service` will show you it has been disabled

> but I do know people doing on-prem kubernetes loads that have had to...

What did they have to do? `systemctl disable systemd-timesyncd` is not very complicated. If they want to create a service, they can have it disable timesyncd iff chrony has started successfully (in an ExecStartPost), or doing a logic chain.

It's extremely practical: you can create very precise logic chains with systemd (if this and that, then...)

> My initial fights with systemd's dependency management meant that disabling its internal DHCP had several cascading consequences with other things that expected networking to be "up". This is to say nothing of the tooling that expects a full-slate of systemd services.

Maybe I can help you with that - I used to run a non systemd DHCP when I needed a rapid DHCP to reduce the TTFB for a specific configuration (read https://news.ycombinator.com/item?id=2755461 if you are not familiar with rapid DHCP)

It did not require much effort, just "inserting" my own service in the dependency chain.

Create a /etc/systemd/system/my-dhcpcd@.service with : (put the…

It's absolutely possible to run an email server in 2016 and I encourage anyone capable to do so!

Email is one of the bastions of the decentralised Internet and we should hang on to it.

Every day more and more people are moving to Gmail/Hotmail/Outlook and while I do understand the reasons, it also puts more and more power into the hands of these providers and the little guy (us) gets more screwed (like marked as junk by default by them :< )

Having said that, here's my check list for successfully delivering email:

- make sure your IP (IPv6) is clean and not listed in any RBL, use e.g. http://multirbl.valli.org/ to check

- make sure you have a correct reverse dns (ptr) entry for said IP and that ptr/hostname's A record is also valid

- make sure your MTA does not append to the message headers your client's IP (ie x-originating-ip), messages can be blocked based only on "dodgy" x-originating-ip (see eg https://major.io/2013/04/14/remove-sensitive-information-from-email-headers-with-postfix/ )

- set up SSL properly in your MTA, there are so many providers giving away free certs nowadays

- SPF, DKIM, DMARC - set them up, properly, this site can come in handy for checking yourself https://www.mail-tester.com/

- do not share the IP of your email server with a web server running any sort of scripting engine - if it gets exploited in any way usually sending spam is what the abusers will do

- last but not least - and while I loved qmail and vpopmail - use Postfix or Exim,…

Still waiting for Dell to fully support Ubuntu in their 2015 XPS 13 model. I made the switch from a Thinkpad after Lenovo burned me too many times. While the keyboard isn't quite as excellent it's still top notch and it's one of the best laptops I've ever owned.

That being said getting everything working in Ubuntu has been a bit of a fiasco [1]. Luckily after some firmware upgrades and the new kernel in 15.04, a lot of issues have been fixed, but the laptop still does strange things waking up from sleep. The worst issue though is that audio still seems to not work in a dual boot configuration. The laptop can't produce sound from the speakers or headphone jack in both Windows and Ubuntu when booting between the two OS's. It seems the hardware gets put in a strange state by either OS and it takes two full reboots after switching from Windows<->Ubuntu to get the audio device to be recognized.

Also HDPI support in Ubuntu is still a little lacking so the beautiful higher-than-retina display sometimes makes things absurdly small. I've seen a lot of progress on this front though.

I really love this device but I'd be lying if I said I didn't miss the excellent out of the box hardware support for Thinkpads in Ubuntu.

[1] - https://major.io/2015/02/03/linux-support-dell-xps-13-9343-2015-model/

Changing SSH port is far more efficacious at reducing nonsense than the Twitter poll in the article suggests:

> "I ran an experiment with a virtual machine exposed to the internet which had sshd listening on port 22. The server stayed online for one week and then I changed the ssh port to 222. The number of attacks dropped by 98%. Even though this is solely empirical evidence, it’s clear that moving off the standard ssh port reduces your server’s profile."[0]

> "In the time that I gathered 7,025 connection attempts to my SSH daemon on port 22 I received 3 on port 24."[1]

Also, great top comment by 16s[2] in this HN thread, "Why putting SSH on another port than 22 is bad idea".[3]

[0] https://major.io/2013/05/14/changing-your-ssh-servers-port-from-the-default-is-it-worth-it/

[1] https://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk/

[2] https://news.ycombinator.com/item?id=6615994

[3] https://news.ycombinator.com/item?id=6615734

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure.

I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time.

The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

[1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-22/