George's Weblog

I have my certificates mounted via NFS on all hosts so that it gives me easy access to them for services that use SSL. The workaround I was using for mail services was to mount like this (from /etc/fstab):

10.20.40.13:/mnt/tank/unix/web/letsencrypt /etc/letsencrypt nfs ro,context="system_u:object_r:postfix_etc_t:s0"

That solves the issue of context for selinux so that postfix can read the files. The issue is that I can't read those same files with dovecot. I had a cron going to copy the certs to /etc/dovecot dir but that was a bit of a hack. So today I dug into the issue and fixed it.

The solution is to add to the current selinux policy so that dovecot can essentially read postfix's files. I suppose it is slightly less secure that way but since they are both part of the mail system I think it's an acceptable risk.

So here is the TE file that I eventually ended up with that allowed dovecot to start successfully. 

module dovecot_read_postfix 1.0;

require {
type postfix_etc_t;
type init_t;
type unconfined_service_t;
type dovecot_t;
class process siginh;
class filesystem remount;
class dir search;
class file { open read };
class lnk_file read;
}

#============= dovecot_t ==============
allow dovecot_t postfix_etc_t:dir search;
allow dovecot_t postfix_etc_t:file { open read};
allow dovecot_t postfix_etc_t:lnk_file read;
#============= init_t ==============
allow init_t postfix_etc_t:filesystem remount;
allow init_t unconfined_service_t:process siginh;

When I renewed my Wired subscription I don't remember reading that I would receive a promotional gift. So it was a pleasant surprise to see an unexpected envelope in the mail. That was, until I opened it.

Inside was a battery power pack complete with charging cable. Looking at it casually, it seemed a bit deformed. After opening it I saw that the battery inside had expanded to the point that it broke the plastic outer housing.

I broke the remaining plastic apart so I could take a look at the battery itself. It was puffed up like a balloon.

Needless to say, I'm glad this stupid little thing didn't explode in my face or burn down my house. If I'm reading the data code correctly, this battery was made two years ago. I'm going to do some additional testing to see if I can determine exactly what went wrong.

I'm using ovirt 4.3x and decided to migrate some VMs to ESXi 6.5.

First thing to do is find the disk file. It can be found easily through the UI of ovirt-engine under Storage/Disks. That table shows the UUID of the folder that the disk is in.

Get a shell on the ovirt node and find the file under /rhev/data-center/mnt/... somewhere probably. It's actually inside the directory that you found above. There are probably three files in there.

Use the qemu-img tool to convert it from raw to vmdk like this:

qemu-img convert -f raw d60c630e-4bc8-44ea-a842-1381f19993b4 -O vmdk newdisk.vmdk -o compat6

It will take a while.

When done, move it to your ESXi datastore somehow (scp, whatever). Then shell into your ESXi machine, make a temporary directory and clone the disk like this:

vmkfstools -i /vmfs/volumes/datastore0/newdisk.vmdk  -d thin /vmfs/volumes/datastore0/newvm-dir/newdisk.vmdk

Fix up the disk controller type in the new vmdk file, change it to lsilogic with your favorite text editor.

cd newvm-dir

vi newdisk.vmdk

Now build a VM the normal way and attach the disk in ESXi. I usually build the VM and don't put any disk on it. Then I move the new disk file into the VMs directory, go back and attach the disk to the VM.

You may have to 'rescue' the system and use dracut -f to get it to boot successfully with a new initramfs image. I generally attach an ISO CDROM and boot to it and use the rescue feature. I've found that CentOS needs this step, Ubuntu and FreeBSD don't seem to require it and happily boot.

Although I haven't encountered this yet, I noticed that the last VM I built on ESXi 6.7 made the default boot EFI instead of BIOS. I think I would have to change the VM to use BIOS if I wanted to use the procedure above.

I received an alert yesterday on my home NAS unit. It indicated that there was an increase in the number of "pending sectors." Looking into the issue, it's really an error writing to the drive which hasn't been addressed and relocated. So the sector might be bad or might be good. If the sector is written to again and fails, it will be relocated. If it's written to without error, the sector will be marked good again.

The way to look at the error counts and other statistics that indicate the health of the drive is by using smart tools. In this case it was the drive at /dev/ada3 which had the problem so I did: 

The significant lines in this case are: 

We had a successful test. So that will get rid of the FreeNAS alert. Just to make sure we are completely okay I'll schedule a scrub of that drive pool and look at the results. If there's any data corruption it should hopefully fix that up.

Proxy arp is a nice feature to have when you're making changes in the network and need things to keep working along the way. It's real easy to use on a Cisco or Juniper router but there are a few caveats when using the feature on pfSense.

To understand what proxy arp does, think of the following situation:

You have a LAN with a network of 10.10.10.0/24.

Elsewhere on the network you have a different network segment, say 10.20.20.0/24. On that segment is a host with the address 10.20.20.100.

You want traffic that used to go to 10.10.10.100 to go to the host at 10.20.20.100 instead. Assume you don't have control over where the traffic is coming from and your only choice is to take the traffic 'as-is' on your network.

The first step in the process is to multihome the server at 10.20.20.100. You want to bring up the IP address 10.10.10.100 on it with a /32 mask (just the one single address). I'm using Centos 7 so I created the file /etc/sysconfig/network-scripts/ifcfg-eth0:1 with the following:

DEVICE=eth0:1
IPADDR=10.10.10.100
NETMASK=255.255.255.255

For some reason I couldn't say PREFIX=32, not sure why. Anyway, you'll then have a multihomed machine. Leave the other interface alone as well as the gateway.

Next step is to put up a /32 route on your next-hop gateway of that host. I'm using pfSense there so I first had to add a gateway for the machine itself so I could add the static route. So I went to System/Routing/Gateways and added a new one with 10.20.20.100 as the gateway address and picking the correct interface. Then to add the static route I went to System/Routing/Static Routes and added a route for 10.10.10.100 to the gateway 10.20.20.100.

I'm running OSPF and have it configured to distribute kernel routes (the kind pfSense creates here) so now I have a route on the network and the address 10.10.10.100 is reachable from everywhere except the the original 10.10.10.0/24 segment. Why? Because the normal behavior for a host on that segment is to send an ARP (who is 10.10.10.100?) on that local segment and wait for a MAC address to be returned. This is where you need the help provided by proxy arp.

A router using proxy arp on a segment notices when there is a smaller route (a /32 perhaps?) elsewhere on the network. When it sees that route, it pretends to be that host and answers the ARP request with it's own MAC. The sending host then uses that MAC as the destination for the Ethernet frame and sends it. The router receives it, strips off the layer 2 header and uses the routing table to decide where to send it.

So the last step in this process is to add a proxy arp address by going to Firewall/Virtual IPs/Add. Choose proxy arp as the type and select the correct network segment. Select 'single address' and then put the address 10.10.10.100/32 there. Save it and you're all set.

Caveats I've found are mostly related to the firewall functions. pfSense likes to make everything stateful. So make sure your paths are symmetrical or you'll find packets getting dropped even if you have an 'allow all' rule in place.