icanhastech?

Free-form digital lenses for your glasses

Wed, 04 May 2016 21:45:37 -0400

Most people don't think twice about glasses. We walk into some eye place, you get a prescription and go pick out new frames. However, there are a ton of different options out there. A couple of these have been significant enough for me to warrant trying to share.

If you are getting new lenses, I highly recommend you ask for free-form digital lenses. This isn't the same thing as a digital lens--the free-form piece is key.

These are the clearest and best pair of glasses that I have ever owned.

Traditional Lenses

Traditional lenses are surfaced by polishing and you end up with a single point in the center of the lens (where your pupil is) that ends up matching your prescription. As you move away from this point, the prescription gets farther away from where it is supposed to be.

If you don't want to read all of this, ask for the Shamir Autograph III (free-form digital lens) in Trivex, but make sure the optical lab won't give you back a lens with 'invisible markings' on the part of the lens that will end up in your frames. (Lenses without markings are an option for single vision lenses)

Free-form Digital Lenses

With a free-form digital lens, your prescription is re-calculated across the entire surface of the lens. This means you're able to use much more of the lens to look through without distortion. For me, it was a night and day difference and I have no plans of ever going back to traditionally surfaced lenses again.

The Shamir Autograph III lens is what I currently have experience with and it is fantastic. However, it has taken a bit of digging/learning to get to where I am now.

Finding a place that is familiar with free-form digital lenses might be a challenge, especially if you are trying to find one that has the smarts and is in your insurance network. It's worth the hunt.

Will this work for you?

If your prescription is between -14.00 to +7.50 with a cylinder to -6.50, you can get the single vision lenses in Trivex. If it's outside of this range, you'll have to ask/do your own research--the ranges are different for the various lens materials out there.

My Adventure

These lenses ship from the factory without digital etchings/markings. However, are later added by the optical lab during their processing. They are supposed to indicate that it was a free-form lens, made of Trivex, in single vision (more on this later) and has the company logo on it. You don't want them.

An optical lab will surface the lens (making it match your prescription) and then mail the lens blank (~3" round piece of lens) back to your eye care place. The local optical place will cut the lens to fit in your frame.

Why these guys would decide to take a precision optical instrument and deface it with this garbage is beyond me. I asked around and their goal was apparently to "make sure consumers can verify they got what they paid for." Which I suppose is great if you are buying your lenses from some shady place. However, it's pretty terrible to look through. When you are wearing the glasses, the 'invisible markings' look like smudges/fingerprints that you can't get rid of. If you take off the glasses and tilt them at just the right angle, you can see that these smudges are actually symbols/text that do indeed indicate the details of the lens.

You can't see these unless you are looking for them. When you are wearing the glasses, they just look like smudges if you try to look through them.

Most optical labs are figuring out that customers hate this and have no interest in trying to look through a company logo on their glasses. As a result, after multiple customer complaints, labs started leaving the etching option off by default.

Make sure you ask if the optical lab can do this, otherwise, you might get back a pair of glasses with smudges (digital etchings) in them that you're going to hate. This must be done at the lab, the local eye care place cannot simply edge the lens differently--especially if you have astigmatism correction.

I've been told that the markings are required for progressive lenses, but optional for single vision lenses

Lens Materials

There are a bunch of these out there. If you have a mild prescription, you probably have polycarbonate lenses. If you have a slightly worse prescription, you probably have high index lenses. Each of these materials has different indexes of refraction (a number that describes how light propagates through it), impact resistance (how hard of a hit it can take before breaking/shattering/denting), abbe value (optical clarity of the material--scale maxes out at 100, your eye is somewhere between 45-50) and a bunch of other values that I'm going to ignore.

You've probably seen/heard of the following materials at some point: polycarbonate, glass, cr-39 plastic, mid/high index plastic, Trivex and maybe others. I'm just going to share information on a couple.

Polycarbonate -- Lightweight, fairly inexpensive, good impact-resistance, abbe value of 30.
Trivex -- Lightweight, slightly more expensive than polycarbonate (less than $40 more), impact-resistance comparable to that of polycarbonate. Abbe value of 43. Is lighter, but slightly thicker than polycarbonate. For me, this equated to the lense being 0.2mm thicker than polycarbonate, which I didn't really care about.
High Index Plastic -- More expensive than Trivex (less than $150 more), impact-resistance much lower than polycarbonate/Trivex. Abbe value between 32-36. Might be a requirement to ensure you aren't rocking coke bottle lenses, depending on your prescription.

Lens Types

There are a bunch of these, but I'm just going to focus on these two as these are your only option in a free-form digital lens at the moment:

Single vision (nothing special, standard prescription)
Progressive (prescription gradually changes across the surface of the lens--can give you distance in the middle and up close if you look through the bottom part of the lens)

Lens Manufacturers

There are a ton of these as well. They will take the various lens materials that are out there and make their own version of them. Most have sales slicks that indicate that they do something special/unique.

Optical Lab

After you've picked out a pair of frames, your local store will likely place an order to an external lab. The lab will be responsible for obtaining the lens blank, surfacing it (making it match your prescription) and then shipping it back to your local store. Most of the larger eye care places have a edging machine in the store that will take the surfaced lens and cut it to fit in your frames.

What if I'm lazy and don't want to research this on my own and I do not care about having my insurance cover it?

Visit adseyeware and place your order. You can mail your frames in after you've placed the order, and they'll take care of the rest. It will probably cost you about $200 if you have your own frames and want Trivex. I have no affiliation with them, they just happened to be the place that did mine and will not send you back lenses with etchings on them.

You will need to know what your current prescription is as well as your PD. The PD is the distance between your pupils. If you have had glasses made in the past, you might be able to call the place that made them for you and ask for it. Some places are silly about giving it to you, so you might need to walk into a eye care place and ask them to measure it for you.

ADS Eyeware also spent the time to help me figure out the difference between the awesome lenses I received from them and the non-free-form lenses I had made at a local place.

Frame Information

Frames all have measurements/sizes on them: bridge width, lens width and the length of the arms. These numbers are usually on the back of the bridge or on the inside of the arms.
Frame manufacturers will sometimes make the same frames in different sizes--a size that fits your face may exist, but might not be in your local store
If you already have frames that fit you well, you can use these numbers as a reference.

Switching to jekyll

Sun, 13 Mar 2016 21:50:37 -0400

I've finally ditched webby as it is no longer being maintained and no longer functions with modern ruby bits. The last commit was 5+ years ago. Perhaps being able to publish will encourage me to actually publish something.

The conversion from webby to jekyll was fairly painless and just involved some perl pie. Fortunately, the URL structure between webby and jekyll are identical, so the old cached links will still continue to function without any redirect hassles. (As long as I don't try to assign categories to the old posts)

Juniper MX: GRE over IPSec with the MS-MIC or MS-DPC

Fri, 11 Mar 2016 10:42:37 -0500

Juniper's MultiServices MIC (MS-MIC-16G) has some fancy features that allow you to do NAT, IPSec termination (~8Gbit/s), etc. on the MX platform. However, documentation for it sucks and J-Tac don't appear to be super familiar with it.

In order to create an IPSec-protected GRE tunnel between two MXs, you need:

A pair of IPs to use for IPSec termination (10.0.0.1/32 and 10.0.0.2/32). These could be your half of the /30 an ISP allocates to you for peering.
A pair of /32s to use for routing traffic to the MS-MIC (10.0.204.50/32 and 10.0.79.50/32). These can be RFC1918 space if you'd like, however, should be separate from your routers primary loopback IP.
A /30 to use for the GRE tunnel itself (10.10.10.0/30). Should be publically routeable if you plan to use the GRE tunnel for moving Internet-facing traffic around.

Add our magic IP to lo0 and route traffic destined to our peers lo0 (10.0.204.50/32) to the MS-MIC (we'll use this as the GRE tunnel destination)

set interfaces lo0 unit 0 family inet address 10.0.79.50/32
set routing-options static route 10.0.204.50/32 next-hop ms-2/2/0.1

Configure interfaces on the MS-MIC:

set interfaces ms-2/2/0 unit 0 family inet
set interfaces ms-2/2/0 unit 1 family inet
set interfaces ms-2/2/0 unit 1 service-domain inside
set interfaces ms-2/2/0 unit 2 family inet
set interfaces ms-2/2/0 unit 2 service-domain outside

Configure the IPSec rules to encrypt traffic from our lo0 destined to our peers lo0:

set services ipsec-vpn rule IPSec term 1 from source-address 10.0.79.50/32
set services ipsec-vpn rule IPSec term 1 from destination-address 10.0.204.50/32
set services ipsec-vpn rule IPSec term 1 then remote-gateway 10.0.0.2
set services ipsec-vpn rule IPSec term 1 then dynamic ike-policy IKE-Policy
set services ipsec-vpn rule IPSec term 1 then dynamic ipsec-policy IPSec_policy
set services ipsec-vpn rule IPSec term 1 then initiate-dead-peer-detection
set services ipsec-vpn rule IPSec match-direction input
set services ipsec-vpn ipsec proposal IPSec-proposal protocol esp
set services ipsec-vpn ipsec proposal IPSec-proposal authentication-algorithm hmac-sha1-96
set services ipsec-vpn ipsec proposal IPSec-proposal encryption-algorithm aes-128-cbc
set services ipsec-vpn ipsec policy IPSec_policy proposals IPSec-proposal
set services ipsec-vpn ipsec policy IPSec_policy perfect-forward-secrecy keys group19
set services ipsec-vpn ike proposal IKE-Proposal authentication-method pre-shared-keys
set services ipsec-vpn ike proposal IKE-Proposal dh-group group19
set services ipsec-vpn ike proposal IKE-Proposal authentication-algorithm sha-256
set services ipsec-vpn ike proposal IKE-Proposal encryption-algorithm aes-128-cbc
set services ipsec-vpn ike proposal IKE-Proposal lifetime-seconds 14400
set services ipsec-vpn ike policy IKE-Policy proposals IKE-Proposal
set services ipsec-vpn ike policy IKE-Policy pre-shared-key ascii-text supersecretkey
set services ipsec-vpn establish-tunnels immediately

You might want to use certificates here for extra security. Shared secrets aren't awesome.

Bind the service sets to the interfaces we previously created

set services service-set IPSec_SS next-hop-service inside-service-interface ms-1/2/0.1
set services service-set IPSec_SS next-hop-service outside-service-interface ms-1/2/0.2
set services service-set IPSec_SS ipsec-vpn-options local-gateway 10.0.0.1
set services service-set IPSec_SS ipsec-vpn-rules IPSec

Configure the MS-MIC to intercept and rewrite the max segment size on TCP packets with the syn flag set to avoid fragmentation issues:

set interfaces ms-2/2/0 unit 3 family inet
set interfaces ms-2/2/0 unit 3 family inet6
set interfaces ms-2/2/0 unit 3 description "TCP MSS Modification"

set services service-set tcp-mss tcp-mss 1360 stateful-firewall-rules permit-all
set services service-set tcp-mss interface-service service-interface ms-2/2/0.3
set services service-set tcp-mss service-set-options enable-asymmetric-traffic-processing

set services stateful-firewall rule permit-all match-direction input-output term accept then accept

set firewall family inet service-filter mss-filter term tcp from protocol tcp tcp-flags syn
set firewall family inet service-filter mss-filter term tcp then service
set firewall family inet service-filter mss-filter term default then skip
set firewall family inet6 service-filter mss-filter_v6 term tcp from next-header tcp tcp-flags syn
set firewall family inet6 service-filter mss-filter_v6 term tcp then service
set firewall family inet6 service-filter mss-filter_v6 term default then skip

enable-asymmetric-traffic-processing is essential if you have the possibility for asymmetric routing in your environment.

Finally, configure our GRE tunnel and assign the TCP MSS modification service set to it:

set interfaces gr-1/3/0 unit 0 tunnel source 10.0.79.50
set interfaces gr-1/3/0 unit 0 tunnel destination 10.0.204.50
set interfaces gr-1/3/0 unit 0 family inet service input service-set tcp-mss service-filter mss-filter
set interfaces gr-1/3/0 unit 0 family inet service output service-set tcp-mss service-filter mss-filter
set interfaces gr-1/3/0 unit 0 family inet address 10.10.10.1/30
set interfaces gr-1/3/0 unit 0 family inet6 service input service-set tcp-mss service-filter mss-filter_v6
set interfaces gr-1/3/0 unit 0 family inet6 service output service-set tcp-mss service-filter mss-filter_v6

You can configure an IPv6 IP here as well if it is in use in your environment.

On your peer router, simply reverse the various IPs.

Verify everything works:

ping 10.0.204.50 source 10.0.79.50

show services ipsec-vpn ipsec security-associations
show services ipsec-vpn ipsec statistics

Ensure that the GRE tunnel IP addresses do not end up in your routing table as this could cause a recursive routing loop. In the above example, we're using the static routes to ensure we don't do this, but, having an export filter for your IGP that rejects the GRE tunel source/destination IPs might be a good thing to add.

You could also build this using interface service-sets instead of the static routes, however, the static routes involve a little less 'magic' and should be a little safer.

chroot()ing OpenLDAP with Heimdal kerberos

Wed, 09 May 2012 07:00:53 -0400

For FreeBSD/Heimdal users who wish to use Kerberos to authenticate users with OpenLDAP, you've likely run into a big of a snag when using more recent (v1.0 or higher) version of Heimdal. This all stems from a security-related change that exists in lib/roken/issuid.c. The test is quite simple and basically detects whether or not the current process has been 'tainted' via uid/gid changes. According to the FreeBSD man page for issetugid(2), this specifically means:

A process is tainted if it was created as a result of an execve(2) system call which had either of the setuid or setgid bits set (and extra privileges were given as a result) or if it has changed any of its real, effective or saved user or group ID's since it began execution.

or, in other words, anything that was executed as root and later drops privs, like slapd. The reason this is problematic for us is that OpenLDAP relies on the environment variable KRB5_KTNAME to set which keytab to open. If a process was considered tainted, Heimdal will ignore this variable and use the system default.

I've seen various patches to the Heimdal libraries/OpenLDAP code that all workaround this issue, but I was interested in a more elegant solution and something that did not require me to maintain my own set of patches to deal with each time I went to upgrade code.

My solution was to simply utilize the chroot option with OpenLDAP. For FreeBSD users, you can simply do the following:

Change the default location of saslauthd's socket, build OpenLDAP with SASL support:

echo "SASLAUTHD_RUNPATH=/usr/home/ldap/var/run/saslauthd">>/etc/make.conf
echo "WANT_OPENLDAP_SASL=yes">>/etc/make.conf

You will need to rebuild openldap and/or saslauthd if the ports for these were already installed.

Create the required directory structure and copy some required files:

mkdir -p /usr/home/ldap/usr/local/etc/openldap /usr/home/ldap/dev /usr/home/ldap/lib /usr/home/ldap/usr/lib /usr/home/ldap/etc/gss /usr/home/ldap/var/run/openldap /usr/home/ldap/var/db/openldap-data /usr/home/ldap/usr/local/lib/sasl2 /usr/home/ldap/usr/local/libexec/openldap /usr/home/ldap/var/run/saslauthd
cp /etc/localtime /usr/home/ldap/etc;cp /etc/group /usr/home/ldap/etc

Update /etc/fstab by appending the required entries to /etc/fstab and mounting the new mounts:

cat /path/to/fstab-ldap >> /etc/fstab
mount -a

Create empty files in key locations to ensure that the ports framework does not delete these directories during upgrades. This is important as we will break our nullfs mounts if the original directories are removed:

touch /usr/local/lib/sasl2/.do_not_delete /usr/local/libexec/openldap/.do_not_delete /var/run/openldap/.do_not_delete

Copy over /etc/passwd and /etc/master.passwd to /usr/home/ldap/etc and update:

cp /etc/master.passwd /usr/home/ldap/etc; cp /etc/passwd /usr/home/ldap/etc; pwd_mkdb -d /usr/home/ldap/etc /usr/home/ldap/etc/passwd; vipw -d /usr/home/ldap/etc

$EDITOR will open and you should then delete any non-default users that aren't essential to OpenLDAP. (Make sure you leave the ldap user). The -d argument to vipw instructs vipw to work on the files in /usr/home/ldap/etc instead of the default (/etc)

Create a new krb5.conf inside the root with the required contents:

echo "[libdefaults]">/usr/home/ldap/etc/krb5.conf
echo "  default_keytab_name = FILE:/usr/local/etc/openldap/ldap.keytab">>/usr/home/ldap/etc/krb5.conf

You will likely want other customizations to this file. For example, specifying the default_realm option.

Copy your keytab for OpenLDAP to /usr/local/etc/openldap/ldap.keytab

Add the following to /etc/rc.conf:

syslogd_flags="-l /usr/home/ldap/var/run/log"
slapd_flags="-r /usr/home/ldap"

Start saslauthd/slapd and do some testing.

Monitoring vSphere (ESXi) with nagios

Sun, 10 Jul 2011 10:32:21 -0400

Monitoring vSphere/ESX(i) in nagios is fairly easy. For FreeBSD users, you'll need to do the following:

Install nagios:

cd /usr/ports/net-mgmt/nagios-devel && make install clean

nagios-devel is only required until 3.2.4 is released as there is a servicedependency fix that will be incorporated into 3.2.4 that makes it easy to do the type of servicedependency that is used in vsphere.cfg.

Install the vmware-vsphere-cli port:

cd /usr/ports/net/vmware-vsphere-cli && make install clean

Download the check_esx3.pl plugin from op5 and place it in /usr/local/libexec/nagios

Configure any remaining components of nagios for your environment.

Use vicfg-user from the vmware-vsphere-cli port to add a nagios user to each of your ESXi hosts:

vicfg-user -server esxihost -username root -e user -o add -l nagios -p securepassword -r read-only

Create a file called vmware_authfile in /usr/local/libexec/nagios (and make sure it's only readable by the nagios user) with the following contents:

username=nagios
password=securepassword

Add the vSphere configuration/dependency config file into your nagios config files and edit as needed.

You'll want to add your own hosts, just follow the existing format. The magic will automatically add the required tests/dependencies as long as the additional hosts follow the same format as the sample esxihost.

Add the vSphere checkcommands for nagios to your config as well.

Reload nagios and you should end up with vSphere monitoring!

Sample Output

check_esx3.pl also includes additional ability to monitor VMs and other information by having it connect to vCenter. You should easily be able to add in these additional tests if you want them by following the existing samples.

snort: Connecting to MySQL with SSL

Sun, 19 Jun 2011 15:45:42 -0400

Tried to configure snort to log to a remote MySQL box and came to the rapid realization that snort did not support doing so via SSL.

The attached diff(1) will force snort to require SSL for MySQL connections. You may find it here.

If you're chrooting snort, you'll need to have devfs mounted therein for /dev/urandom. Under FreeBSD, you would simply edit /etc/fstab and add a line similar to the following:

none                    /path/to/snort/chroot/dev     devfs   rw      0       0

Then run 'mount -a' to mount it.

You'll need to copy your certificates into the root. If you wish to make a non-SSL connection, you'll need to undo the patch. Make sure you did not leave the private key world readable.

UPDATE:

Database output functionality is being deprecated in snort in favor of utilizing unified2 with barnyard2.

FreeBSD: TrueCrypt 7.0a in the ports tree!

Sat, 11 Jun 2011 13:20:37 -0400

An experimental port of TrueCrypt has been added to the FreeBSD ports tree. Additional details can be found here.

FreeBSD: Redundant DNS with CARP

Sun, 28 Feb 2010 10:45:48 -0500

Improve reliability with CARP and redundant DNS on two boxes. Almost everyone already has (at least) two nameservers, so why not add CARP into the mix to make it appear as if they're always available?

This setup assumes two nameservers. Both nameservers will have a total of 3 IPs assigned to them, two of which are the floating CARP IPs and one of which is a unique management IP for each box. Each nameserver will be the CARP backup for the other nameservers primary nameserver IP. If one goes down, the other will assume responsibility for the IP.

You'll need to assign your nameservers two new IPs (to be used for management) and take the original pair of IPs and we'll use those for the carp interfaces.

Rebuild/install your kernel with (or load the carp module via /boot/loader.conf):

device      carp

Edit /etc/rc.conf to add:

cloned_interfaces="carp0 carp1"
ifconfig_carp0="create"
ifconfig_carp1="create"

Setup the CARP interfaces:

I set the vhid's to be the last octet of the floaty IP, however, you can set them to be whatever you want as long as they match on both boxes.

On ns1: Create /etc/start_if.carp0 with the following:

#!/bin/sh
ifconfig carp0 vhid XX advbase 1 advskew 10 pass supersecretpasswordhere <ns1.ip> netmask <ns1.netmask>

Create /etc/start_if.carp1 with the following:

#!/bin/sh
ifconfig carp1 vhid YY advbase 2 advskew 10 pass othersupersecretpasswordhere <ns2.ip> netmask <ns2.netmask>

Then run:

chmod go-rwx /etc/start_if.carp*;chmod +x /etc/start_if.carp*

On ns2: Create /etc/start_if.carp0 with the following:

#!/bin/sh
ifconfig carp0 vhid YY advbase 1 advskew 10 pass supersecretpasswordhere <ns2.ip> netmask <ns2.netmask>

Create /etc/start_if.carp1 with the following:

#!/bin/sh
ifconfig carp1 vhid XX advbase 2 advskew 10 pass othersupersecretpasswordhere <ns1.ip> netmask <ns1.netmask>

Then run:

chmod go-rwx /etc/start_if.carp*;chmod +x /etc/start_if.carp*

carp0 on both boxes will be its PRIMARY IP whereas carp1 will be the SECONDARY IP on both. In a non-failover scenario, this means that carp0 on both boxes should show up as MASTER and carp1 should show up as BACKUP.

Ensure named is configured to bind to the management IP (for zone transfers, etc.), ns1.ip and ns2.ip (on both boxes!) or ensure that it listens on *.

Add this to /etc/sysctl.conf for some extra logging info.

net.inet.carp.log=2

Reboot. Your primary box should come up with ns1.ip as MASTER and ns2.ip as BACKUP. Your secondary box should come up with ns2.ip as MASTER and ns1.ip as BACKUP. Check ifconfig and dmesg to confirm.

CARP traffic is multicast and you may need to alter firewalls as appropriate to allow it. The destination is VRRP.MCAST.NET/224.0.0.18. For defining masters/slaves, etc. in bind you will want to reference the management IPs of the boxes, not the floating CARP addresses.

You can actually skip using the start_if.* files if you elect to put the ifconfig statements into rc.conf. In order to limit access to your CARP authentication key, you would need to change the permissions on rc.conf which could be bad in certain situations.

ESX Note: If you're trying to do this with a box in VMware, you'll need to disable the vSwitch security features (accept: promisc, forged transmits, mac changes). This is not advisable in production as any VM on that switch can sniff traffic from any other VM. For my setup at home, I simply allocated a second NIC and a second vSwitch and made the security changes on the dedicated vSwitch. No other VMs should share this other vSwitch where the security features have been disabled.

FreeBSD: authenticated smart relay client with sendmail

Mon, 01 Feb 2010 20:01:38 -0500

One may find it necessary to configure sendmail to authenticate and relay via another SMTP server, such as one provided by your ISP. In order to do this under FreeBSD, sendmail needs to be rebuilt with support for SASL and a few config changes are required.

cd /usr/ports/security/cyrus-sasl2 && make install clean

Untick AUTHDAEMOND, OTP and NTLM.

Edit /etc/make.conf and add:

SENDMAIL_CFLAGS=-I/usr/local/include -DSASL=2
SENDMAIL_LDFLAGS=-L/usr/local/lib
SENDMAIL_LDADD=-lsasl2

Rebuild/reinstall sendmail:

cd /usr/src/lib/libsmutil;make cleandir && make obj && make
cd /usr/src/lib/libsm;make cleandir && make obj && make
cd /usr/src/usr.sbin/sendmail;make cleandir && make obj && make && make install

Create /etc/mail/authinfo with the following content (assuming your SMTP server supports PLAIN auth within TLS):

AuthInfo:smtp.server.host "I:username" "P:password" "M:PLAIN"

cd /etc/mail && makemap hash authinfo<authinfo;chgrp smmsp authinfo*;chmod o-rwx authinfo*
cp freebsd.submit.mc `hostname`.submit.mc;cp freebsd.mc `hostname`.mc

Edit /etc/mail/`hostname`.submit.mc and /etc/mail/`hostname`.mc and add the following before the msp line:

FEATURE (`authinfo')
define(`SMART_HOST', `smtp.server.host')

/etc/rc.d/sendmail stop && /etc/rc.d/sendmail start

Profit!

If you upgrade the cyrus-sasl port, you may need to rebuild/reinstall/restart sendmail as indicated in step 3. src-all is required from svn.

ESXi saga continues: Dell OMSA sillyness

Sun, 06 Dec 2009 12:24:45 -0500

When attempting to install the Dell OMSA extensions on ESXi, I ended up with an error indicating that the SMBIOS values reported by the host didn't match the metadata stored in the crossoem-dell-openmanage-esxi6.1-0000.zip file.

Encountered error NoMatchError:
The error data is:
   Id          -
   Message     - No bulletins for this platform could be found.  Nothing to do.
                 Detailed reasons why no bulletins match: This Vib supports
                 hardware vendor 'Dell' but BIOS reports vendor as 'Dell Inc.
                 ' This Vib supports hardware vendor 'Dell Computer Corporation'
                 but BIOS reports vendor as 'Dell Inc.                ' This Vib
                 supports hardware vendor 'Dell Inc.' but BIOS reports vendor as
                 'Dell Inc.                '
   Errno       - 13
   Description - No matching bulletin or VIB was found in the metadata.

Apparently, esxupdate thinks the manufacturer is "Dell Inc. " instead of "Dell Inc." Seems sort of silly.

unzip crossoem-dell-openmanage-esxi6.1-0000.zip
unzip metadata.zip
Edit platforms.xml and remove the hwPlatform lines, save the file and add/overwrite platforms.xml in metadata.zip
untar crossoem-dell-openmanage-esxi6.1-0000.vib (which is actually a debian dpkg)
Edit descriptor.xml and remove the hwPlatform lines
Recreate the vib (without the pkcs7 sig file and the newly edited descriptor.xml) with: ar -r crossoem-dell-openmanage-esxi6.1-0000.vib debian-binary control.tar.gz data.tar.gz short.rpm descriptor.xml
Recreate crossoem-dell-openmanage-esxi6.1-0000.zip, which should contain the .vib and metadata.zip.
Login to your host and run: esxupdate --nocache --nosigcheck --bundle crossoem-dell-openmanage-esxi6.1-0000.zip update

/tmp # esxupdate --nocache --nosigcheck --bundle cross_oem-dell-openmanage-esxi_6.1-0000.zip update
cross_oem-dell-openmanage-esxi_6.1-0000.zip                      ########################################################################################## [100%]

Unpacking cross_oem-dell-openmanage-esxi_6.1-0000.vib            ########################################################################################## [100%]

Installing packages :cross_oem-dell-openmanage-esxi_6.1-0000     ########################################################################################## [100%]

Running [/usr/sbin/cim-install.sh]...
ok.
Running [/usr/sbin/vmkmod-install.sh]...
ok.
/tmp #

icanhastech?

Free-form digital lenses for your glasses

Traditional Lenses

Free-form Digital Lenses

Will this work for you?

My Adventure

Lens Materials

Lens Types

Lens Manufacturers

Optical Lab

What if I'm lazy and don't want to research this on my own and I do not care about having my insurance cover it?

Frame Information

Switching to jekyll

Juniper MX: GRE over IPSec with the MS-MIC or MS-DPC

Add our magic IP to lo0 and route traffic destined to our peers lo0 (10.0.204.50/32) to the MS-MIC (we'll use this as the GRE tunnel destination)

Configure interfaces on the MS-MIC:

Configure the IPSec rules to encrypt traffic from our lo0 destined to our peers lo0:

Bind the service sets to the interfaces we previously created

Configure the MS-MIC to intercept and rewrite the max segment size on TCP packets with the syn flag set to avoid fragmentation issues:

Finally, configure our GRE tunnel and assign the TCP MSS modification service set to it:

On your peer router, simply reverse the various IPs.

Verify everything works:

chroot()ing OpenLDAP with Heimdal kerberos

Change the default location of saslauthd's socket, build OpenLDAP with SASL support:

Create the required directory structure and copy some required files:

Update /etc/fstab by appending the required entries to /etc/fstab and mounting the new mounts:

Create empty files in key locations to ensure that the ports framework does not delete these directories during upgrades. This is important as we will break our nullfs mounts if the original directories are removed:

Copy over /etc/passwd and /etc/master.passwd to /usr/home/ldap/etc and update:

Create a new krb5.conf inside the root with the required contents:

Copy your keytab for OpenLDAP to /usr/local/etc/openldap/ldap.keytab

Add the following to /etc/rc.conf:

Start saslauthd/slapd and do some testing.

Monitoring vSphere (ESXi) with nagios

Install nagios:

Install the vmware-vsphere-cli port:

Download the check_esx3.pl plugin from op5 and place it in /usr/local/libexec/nagios

Configure any remaining components of nagios for your environment.

Use vicfg-user from the vmware-vsphere-cli port to add a nagios user to each of your ESXi hosts:

Create a file called vmware_authfile in /usr/local/libexec/nagios (and make sure it's only readable by the nagios user) with the following contents:

Add the vSphere configuration/dependency config file into your nagios config files and edit as needed.

Add the vSphere checkcommands for nagios to your config as well.

Reload nagios and you should end up with vSphere monitoring!

snort: Connecting to MySQL with SSL

FreeBSD: TrueCrypt 7.0a in the ports tree!

FreeBSD: Redundant DNS with CARP

Rebuild/install your kernel with (or load the carp module via /boot/loader.conf):

Edit /etc/rc.conf to add:

Setup the CARP interfaces:

Ensure named is configured to bind to the management IP (for zone transfers, etc.), ns1.ip and ns2.ip (on both boxes!) or ensure that it listens on *.

Add this to /etc/sysctl.conf for some extra logging info.

Reboot. Your primary box should come up with ns1.ip as MASTER and ns2.ip as BACKUP. Your secondary box should come up with ns2.ip as MASTER and ns1.ip as BACKUP. Check ifconfig and dmesg to confirm.

FreeBSD: authenticated smart relay client with sendmail

cd /usr/ports/security/cyrus-sasl2 && make install clean

Edit /etc/make.conf and add:

Rebuild/reinstall sendmail:

Create /etc/mail/authinfo with the following content (assuming your SMTP server supports PLAIN auth within TLS):

Edit /etc/mail/hostname.submit.mc and /etc/mail/hostname.mc and add the following before the msp line:

Profit!

ESXi saga continues: Dell OMSA sillyness

Edit /etc/mail/`hostname`.submit.mc and /etc/mail/`hostname`.mc and add the following before the msp line: