Regarding Dave Taylor's series on the Mars Lander game in the September, October and
November 2016 issues: I appreciate the way he builds the program over three months in the magazine. Is
there somewhere I can download the finished program, so I can peruse and play with
it?
—
John
The finished program is available at www.linuxjournal.com/files/linuxjournal.com/mars2.txt.—Ed.
I found Kyle Rankin's “Simple Server Hardening” article in the October 2016 issue to be very useful, and I also look forward to more such tips, such as hardening of services that need to be on—for example, a mail server.
I have one comment: if we disable passwords altogether and allow access using SSH
keys only, is there still a need to disable root login over SSH? The problem with
reaching root via a non-root login (using sudo or SSH) is then your root is only
as secure as such a non-root login. I personally don't even have a password for root,
although I permit keys-only SSH logins to root. I would be glad if you could highlight
risks with this arrangement, as against sudo and so on.
—
Mayuresh
Kyle Rankin replies: This is a great question. Yes, even if you disable password login altogether, you still should disable root login both over SSH and locally, and use sudo instead. The core idea with requiring sudo for root access instead of using su is that it makes it easy to revoke any individual admin's access to root without having to change some central, shared password. Even if you require SSH keys for login, requiring sudo still provides extra protection in the case of a compromised key.
Attackers who have compromised an admin's SSH keys still have one extra barrier to the root account: they may be able to ssh in to a server as the admin using the admin's key (if the admin didn't take the extra step of password-protecting the keys), but the attackers still have to figure out the admin's personal password to be able to sudo to root. In your scenario, if your personal key were compromised, attackers would have direct access to root on all of your machines. Scenarios like this are why it's so important never to share personal keys between admin, password-protect your keys, pick good passwords for sudo, and never allow users to sudo up to root without their password.
Shawn Powers' “Hodge Podge” article in the October 2016 issue was an interesting article, as usual.
In the article, he mentioned several economical cloud options. I wonder
whether he has evaluated SDF.org (https://sdf.org). There are various tiers available to suit
various needs, the most basic costing only a one-time fee for life on a shared
cluster. There are VPS options as well at the higher end. How do these options
figure in comparison with others that he mentioned?
—
Mayuresh
Shawn Powers responds: I'd never heard of SDF.org, but when I visited the site, I couldn't find VPS options. I did see free shell access, which is cool, but that's all I could find.
In Shawn Powers' “Hodge Podge” article in the October 2016 issue, he mentioned his love for Synology and GPS trackers. I think I share the same passion. In his quest for fun gadgets and programs, I would like to introduce Traccar. I use the free program called Traccar (www.traccar.org) to monitor the movements of my car. I installed the Traccar server on my Synology and the Traccar client on an old unused Android smartphone (with GPS). I installed the smartphone in my car and connected the smartphone to my car battery. On the smartphone, I installed a firewall app to minimize data traffic to and from Google (I'm not interested in updates or other stuff).
When the car is parked in the vicinity of my house, the smartphone uses the Wi-Fi of my AP. In this way, I minimize data traffic on my pre-paid data bundle. Only when I'm driving around GPS coordinates are sent to the Traccar server using the pre-paid data bundle. The client is set to an interval of one minute. Depending on the cost of your pre-paid data bundle and the amount of travel, you will use up $10 in several months.
The Traccar server stores all coordinates (of multiple devices if needed) in a MySQL database. Via a web interface, you can locate your GPS device or see where the GPS device, in my case my car, travels or has traveled to.
Next, I wrote a C-program that does a MySQL query on the Traccar database. Whenever my car starts moving and moves beyond a pre-defined offset, the C-program sends an email, notifying me that the car is moving. The C-program also emails me when the car is stationary with its present position (street name and city). The C-program is running on a Raspberry Pi next to another beautiful program: Domoticz (https://domoticz.com).
There you go—a second life for your smartphone and lots of fun.
—
Roland
Horsten
Shawn Powers responds: Very cool! I wonder if the program would record and upload only while within range of home Wi-Fi. It would be a great use for old phones and wouldn't require any cell service at all. Either way, I'll check it out. Thanks!
I'm one of the linux-wpan maintainers in the Linux kernel as well as the wpan-tools maintainer.
That this project was picked up for an article series in Linux Journal was a really nice surprise [see Jan Newmarch's articles in the November and December 2016 issues, as well as the final article in this issue].
Reading the first article, I have a few items I wanted to bring up:
In the article Jan writes that the at86rf230 module needs to be loaded manually. That should not be needed and has not been in my testing so far. The device tree overlay he enabled should make sure that the driver is auto-loaded as well. Maybe that's something worth checking in his system.
In the Python example, he uses TCP. I really would recommend using UDP for examples here. In his test setup, it will not make much of a difference, but in these networks, it can be really lossy and the TCP handshake makes things more complicated. In the end, you normally do not need a stream protocol for these types of networks.
Using UDP for this example has the additional benefit that the kernel can apply next header compression (NHC, RFC6282) for UDP. If you use the right port range, that can save 2 bytes from the UDP header in each packet. (The port range is reduced to only 16 ports, starting from port 61617.)
A good article overall. Thanks for doing it and looking forward to the
next episodes.
—
Stefan
Schmidt
Jan Newmarch responds: Thanks Stefan! Yes, you are right on both counts. I manually loaded the drivers in order to test if it was working. Once confirmed, reboots and the device tree load the drivers as needed. I should have mentioned that I loaded them manually only as a test and after that it no longer would be needed.
I was undecided as to whether to use TCP or UDP. UDP is the protocol of choice for low-power systems, but I thought that readers might be more familiar with TCP programs. The RPi can handle either; it has enough capabilities. I my third article (in this issue), I'm using the CoAP library aiocoap, and that is UDP-based.
I loved Susan Sons' “Holy Triage, Batman!” article in the November 2016 issue. So much good
advice! Thank you!
—
Mike
I just finished reading Reuven M. Lerner's At The Forge (“Preparing Data for
Machine Learning”) in the November 2016 issue, which was great and had me
craving a burrito! But I noticed a typo: in
the Resources section, the Data Science Weekly newsletter URL should be
a .org and not a .com. The correct URL is datascienceweekly.org.
—
Terrill
