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
I first tried to install Mac OS onto a VM back in 2010 or 2011 I think. I’ve come back to the task from time to time and have never been successful, but truthfully until recently all the virtual machines I’ve created on Cinnamon had been too slow to be useful anyway. Now that I have Cinnamon doing virtual machines well, I came back to the Mac – at the same time I was doing other VMs, and I didn’t keep careful track of what I did to get it up. This document is meant to record what I remember of what I did the first time, and then to do it again and keep better records.
Continue reading Installing Mac OS on KVM
I found out today something I am sure to forget.
In every zfs dataset there is an invisible directory (by invisible, I mean that it does NOT show up with ls -a) name .zfs. In side this directory are two subdirectories, shares and snapshots.
The snapshots subdirectory is a perfectly serviceable read-only access to all the snapshots. Viz:
Continue reading Invisible zfs snapshot directory
I had in mind (still do) to use Cinnamon as a host for virtual machine. In fact, I have had that idea in the back of my mind for many years. Recently that idea percolated up to the top again, and one thing I did was to buy some additional ram for it, I bought a 16G stick and tried to add it. It wouldn’t boot. The very poorly written manual on the motherboard seems to suggest that it absolutely requires one to have balanced sticks in the dimm slots. I find that hard to believe, but decided it couldn’t hurt to comply, and bought another stick, so I would have 2 8G sticks, and 2 16G sticks, 48G.
It still wouldn’t boot. But I noticed that this doesn’t look like the hardware is failing – it gets up into Xen and then stops. I don’t think this is a hardware problem with the memory.
After some googling around I found an article on the Suse website with a similar thing, saying that Dom0 won’t come up if it has more than 32G of memory, and offering a solution.
I’m very ignorant about Xen. I have never really gotten beyond installing it, with my Cinnamon ubuntu installation in Dom0 and using all the resources. But, but it is clear of course that the right way to do this is for the Dom 0 to be small and confined to its management job, and Cinnamon should actually be a Dom U.
What seems to be true is that if you do not specify on the command line, the Dom 0 will come up with all the memory. And that if you have more than 32GB of memory for it to come up with it will fail. Thus if you have more than 32GB of memory, you MUST avail yourself of the command line to limit the memory available to Dom 0.
I added to the linux command line in the default grub,:
And the box came up fine. Once I manage to get Cinnamon and it’s functions into separate Dom U, I will reduce the dom0 down to 1 G or so.
I hosed up the configuration of libvirt on Cinnamon, trying to change the network definition.
It was so fouled up I decided to remove and reinstall libvirtd-bin, qemu, and virt-manager.
After the reinstall, the default network did not reappear, and I went looking for how to reinstall it. In the end I had to piece together various information, but the upshot is that the definition of networks for libvirt is in /usr/share/libvirt/networks. This directory was missing for me, and I had to recreated it:
root@cinnamon:~# mkdir /usr/share/libvirt/networks
root@cinnamon:~# cd /usr/share/libvirt/networks
root@cinnamon:/usr/share/libvirt/networks# touch default.xml
root@cinnamon:/usr/share/libvirt/networks# chmod 0777 default.xml
root@cinnamon:/usr/share/libvirt/networks# emacs default.xml
What I put into the file was:
<bridge name=”virbr0″ />
<ip address=”192.168.122.1″ netmask=”255.255.255.0″>
<range start=”192.168.122.2″ end=”192.168.122.254″/>