Category Archives: raspberry pi

arch linux, gateways, ipv6, linux, networking, raspberry pi, raspbian, systemd, ubuntu, vpn

Network Configuration and Services

I have written a lot of drivel previously about the various aspects of managing network service, as I’ve tried to figure out the improvements that have been made in linux networking over the last 30 years. I don’t read the kernel threads, and don’t know what’s happening a lot of the time, and haven’t been good about being attentive to release notes, so I get behind and then have to catch up. Previous efforts to catch up have usually been in a hurry when something was busted, and weren’t comprehensive.

This time I have tried to be a bit more comprehensive, so I could settle on the set of solutions and tools I am going to use on the 20 or so different boxes where I have to set this stuff up. A few of them actually need something special, but not most of them. Still, things have to be consistent, and I need to know what I’m doing – at least better than I previously did.

Continue reading Network Configuration and Services →
backup, gateways, linux, networking, openssh, raspberry pi, security, virtualization

Protecting ssh

I have a dozen or so boxes, mostly little raspberry pis, out in people’s houses which let me do backups for them, and attach to their networks. I’ve documented this before in “Gateway pi”, “Memory on the Gateway Pi”, and “Timemachine on Gateway pi” for example.

Connection between these boxes and my house is with SSH, and I use openssh certificates as described in “Using openssh certificates” and “Re-signing Openssh Certificates”. However, there has always been a little nagging problem, which is that these boxes must (re-)establish their connection to me automatically upon reboot, without user intervention. This means that the private keys that accompany the certificates cannot be encrypted, for that would require human intervention.

So there is a risk. Those raspberry pis have upon them a certificate and a private key which would enable access to boxes in my house. Not completely unrestricted access, and not root access, but nevertheless.

Continue reading Protecting ssh →
arch linux, gateways, ipv6, linux, mac, networking, openssh, postfix, raspberry pi, raspbian, security, ubuntu, vpn

IPv6 Re-implementation

This is a follow up to the activities in IPv6 implementation, which was published on March 2nd and revised up through March 19th, as new challenges were addressed. Since March 19th a great deal of what I wrote has been revised, as I have learned a lot more.

The main issue was that there remained a number of problems with the implementation of IPv6 in my residence.

  • The biggest was the question how to handle the delegated prefix, particularly in renumbering. Over the course of the last several months I have to note that Comcast has never changed my prefix, except early on, when I forced it to do so by changing my DUID. And I don’t think it likely that my prefix would change unless some great catastrophe befalls which results in my being down for a very extended period – like 30 days; or more likely there is some change in my service (a change in ISP, or perhaps fiber arriving in my area).
  • The first implementation required that I make patches to the code of my router. This meant that I would have to figure out how to carry those patches forward in the event of firmware updates from Ubiquiti, the maker of the Edgerouter-X that I am using.
  • The implementation was pretty fragile, with a lot of unrelated bits in different places. In particular there was a lot of hand-waving in trying to assign and maintain a separate network for the virtual machines on one of the interior boxes.
Continue reading IPv6 Re-implementation →
arch linux, boot issues, gateways, linux, networking, raspberry pi, raspbian, ubuntu

Waiting for networks

I was revising some things in my startup scripts. I have a sort of generalized startup script in all the boxes in my constellation, which is capable of doing 8 or 10 different things that various of the boxes need to do at startup.

For example, the various gateway boxes need to open up (auto)ssh connections to my house with reverse tunnels so I can reach them. On some boxes I want them to open a vncserver so I can get a graphical environment up. On some others they may need to mount some filesystems, with smb or nfs. On some of them I want them to figure out where their router is, in case I want to open up their router in a browser. On some I need them to establish the keychain.

Continue reading Waiting for networks →
raspberry pi, raspbian

Raspberry pi updates

It has become a constant annoyance that every time I build a new Raspberry Pi, the thing which is the most difficult is doing updates. I have scripts written to set everything up, but the first thing the script does is attempt to update software. Before I even reach that point, the first thing the Pi itself does is ask to update software. And it always fails.

I think this may be because of where I live. I think that the Raspbian (now Raspberry Pi OS apparently) mirrors must have one locally that is unreliable, and it gives me that one.

Two things I need to do. One is that it tries to connect using ipv6, and fails. I have to tell it to use ipv4. So one thing I end up having to do is tell apt not to use ipv6: 

echo 'Acquire::ForceIPv4 "true";' > /etc/apt/apt.conf.d/99-useipv4

The second thing is to change the location of the mirror. One can look up the mirrors at https://www.raspbian.org/RaspbianMirrors, and pick one nearby, and replace the entry in /etc/apt/sources.list.

backup, gateways, mac, networking, openssh, raspberry pi, raspbian

Timemachine on Gateway pi

Some people for whom I provide some kinds of support with gateway pis, use Macs. For the pc folk – at least for those on Windows 10, I’ve been seting up to do the filehistory thing, and putting the filehistory onto the /backup drive on the gateway pi. Then it gets sent here overnight. I wanted to do the same for the folks who have Macs, of which there are several.

Continue reading Timemachine on Gateway pi →
fedora, gateways, linux, mail, postfix, raspberry pi, raspbian, saslauthd, security

No Worthy mechs

I just built another little gateway pi, on Raspbian. It is a newer Raspbian than I used for the others. And newer is better, right? But when the little fellow came up, postfix claimed it couldn’t relay through tarragon, because it couldn’t accomplish login. Sasl authentication failed, no worthy mechs.

I remember good old “no worthy mechs” from way back when, always thought it a very cool error message. But why in the heck am I getting this? I’m not doing anything fancy.

I had a vague nagging feeling from some old Fedora problems, long ago. Could it be that I have to install some kind of sasl library, even to do plain authentication? Poked around a little. Eventually did an apt install libsasl2-modules and sasl2-bin. Sure enough, they actually installed.

And afterwords postfix came up and send the mail out of the queue. I’ll be dipped in … I am surprised. This was not something I had to do before. Is this an improvement in Raspbian. Don’t package any sasl mechs, make the poor sod figure out why sasl authentication won’t work.

This is to help me remember the next time this happens.

backup, gateways, linux, networking, raspberry pi, ubuntu

Memory on the Gateway Pi

I now have 8 of these gateway boxes out there. This morning as I was checking backups on one of them, I observed that it took quite a long time to respond. I ran a top on it and was horrified to see that its memory use was 100% and so was its swap. Holy @#$%!@ Batman!

Most of the memory was being used by the lxpanel. And (hangs head in embarrassment) there were actually two lxpanels running – one for the console and one in the vnc window I launch at startup.

It seems the lxpanels leak. I don’t know how badly, but it doesn’t matter. These boxes are meant to run forever so even a tiny leak is eventually fatal.

Well this was simple. I will seldom, if ever, need to get into a graphical environment remotely, and if I do I can always start vnc from the command line. So I took out the startvnc from the startup script. And I have even LESS need for a graphical console since there is not even a monitor on these things. So I set the default systemd target to multi-user.target.

Did this on all the gateways that are running on pi-zeros. Those few running on bigger ubuntu boxes I didn’t really have the problem anyway.

After rebooting them they come up with no lxpanels. I’ll watch the memory use, but I think this will fix the problem.