There are essentially three parts to setting up VPN: authentication, kernel configuration, and routing tables.

Authentication

Authentication is done by the IKE protocol, which is implemented by Strongswan. Setting it up requires configuring the files /etc/ipsec.conf and /etc/ipsec.secrets.

There are two versions of IKE: IKEv1 and IKEv2. The newer version is better in a number of respects, but Mac OS X 10.9 and earlier use racoon as the IKE client, and racoon only supports IKEv1. Thus, I set up two VPN server connections with Strongswan, one for each protocol, and Strongswan automatically selects the right version upon client connection.

My goal was to set up certificate-based authentication of the server, but password-based authentication of clients. Strongswan supports PEM certificates, and so the same key that is used for website HTTPS or other TLS authentication works fine (but see below with regard to the OS X client). Both versions of IKE support various combinations of authentication protocols. For IKEv1, we want hybrid XAUTH authentication, and for IKEv2, we want EAP authentication of the remote client. In Strongswan, this is done by configuring “leftauth=pubkey” and other parameters, and then “rightauth=xauth” (for IKEv1) or “rightauth=eap-[form]” (for IKEv2).

Passwords are placed in the /etc/ipsec.secrets file. It seems that configuring an EAP password also automatically configures the XAUTH password.

Strongswan on Ubuntu is subject to Apparmor protection, which means that the Apparmor configuration needs to be adjusted to permit Strongswan to read the server’s private key if the key is placed in a location outside of /etc/ipsec.d.

For configuring IKEv2, this page provides information on the setup. The main point is that iOS only supports EAP-MSCHAPv2 as the authentication protocol.

Kernel Configuration

The kernel needs to be configured with parameters to allow for packet forwarding from the server. This is best done using a new file in /etc/sysctl.d.

Routing Tables

Finally, the routing tables need to be set up to accept both the authentication packets and the encrypted VPN data packets, and to forward the VPN data to their destinations.

Client Configuration

The IKEv2 client in iOS appears to work out of the box. For OS X 10.9, a specialized racoon configuration file is needed. Out of the box, the OS X Cisco VPN client supports pre-shared keys plus passwords and mutual certificates plus passwords, but it does not support hybrid authentication without a certificate on the client side.

When a VPN connection is initiated in OS X, the system creates a new configuration file in /var/run/racoon, which the default configuration file /etc/racoon/racoon.conf will read. The key is to start by obtaining the automatically created file (just initiate a VPN connection and copy whatever file shows up in /var/run/racoon), and then rewrite it and adjust /etc/racoon/racoon.conf to include that adjusted file.

The main adjustment is to remove references to the client certificate, and under each proposal block to change the authentication_method parameter to hybrid_rsa_client. Additionally, because of a bug with OS X VPN connections timing out due to rekeying, I changed the lifetime parameter to a larger value.

Finally (and this was the most frustrating bug), the server certificate as parsed by the OS X client does not include bundled intermediate certificates. (I’m not sure if this is the fault of Strongswan not sending intermediate certificates, or racoon ignoring them when sent.) So this means that you have to manually import the intermediates into the OS X keychain before the server certificate will be accepted.

This is a working collection of rules for slash signatures used in documents electronically filed before various government bodies.

Slash signature rules are greatly inconsistent. Most bodies follow a convention of “/s/ [name]” but there are exceptions, notably the Ninth Circuit and the U.S. Patent and Trademark Office. Some require the name to be the person’s actual name; others permit freeform text. Many bodies impose no specific requirement but recommend the ordinary convention; still others impose no requirement at all.

Courts of Appeals

Federal Circuit: Rule 25(d): Where the court’s rules require a signature on a document, the name of the filer whose log-in and password is used to submit a document may be preceded by “/s/” and typed in the space where the signature would otherwise appear.

Eleventh Circuit: CM/ECF Guide to Filing Rule 3.2: The identity of the Attorney Filer submitting the electronically filed document must be reflected at the end of the document by means of an “s/[attorney’s name]” block showing the attorney’s name, followed by the attorney’s business address, telephone number, and e-mail address. Graphic and other electronic signatures are discouraged.

Ninth Circuit: Rule 25-5(e): Electronic filings shall indicate each signatory by using an “s/” in addition to the typed name of counsel or an unrepresented party.

Fourth Circuit: Rule 25(a)(9): The name of the filing user under whose log-in and password the document is submitted must be preceded by an “s/” and typed in the space where the signature would otherwise appear.

Second Circuit: Rule 25.1(e): [no requirement:] A PDF need not include a manual signature.

D.C. Circuit: Rule 32(a)(1): The name of the filer under whose log-in and password a document is submitted must be preceded by an “/s/” and typed in the space where the signature would otherwise appear, followed by the firm name, if any, and the attorney’s or party’s street address, telephone number, and e-mail address.

District Courts

Central District of California: Local Rule 5-4.3.4: Electronically filed documents must also include a signature block as provided in L.R. 11-1, and the signature shall be represented on the signature line with either an “/s/” or a digitized personalized signature.

Federal Agencies

Federal Communications Commission: 47 CFR 1.52: If pursuant to §1.429(h) a document is filed electronically, a signature will be considered any symbol executed or adopted by the party with the intent that such symbol be a signature, including symbols formed by computer-generated electronic impulses.

U.S. Patent and Trademark Office: 37 CFR 1.4(2)-(3): [providing numerous requirements for signatures, including:] The S-signature must consist only of letters, or Arabic numerals, or both, with appropriate spaces and commas, periods, apostrophes, or hyphens for punctuation, and the person signing the correspondence must insert his or her own S-signature with a first single forward slash mark before, and a second single forward slash mark after, the S-signature (e.g., /Dr. James T. Jones, Jr./)

U.S. International Trade Commission: EDIS handbook, ch. II.J(2): such document shall be deemed signed provided that such document is filed using the user ID and password of the signatory and contains the physical signature of the registered user using an optical scan format or a typed “electronic signature,” e.g., “/s/Jane Doe.”

Federal Trade Commission: 16 C.F.R. 4.2(f)(1): For documents filed electronically using the Office of the Secretary’s electronic filing system, documents must be signed using a scanned signature image, an “s/” followed by the name of the filer using the electronic filing system, or another signature method as the Secretary may direct.

This is a post of tips for altering my dress shirts for the next time that I do it.

Measurements and Pattern Drawing

Take the waist and hip measurements from an existing shirt. Take the chest, biceps, and sleeve length measurements from the body since those are too variable based on the shoulder dimensions.

Avoid flaring at the hips too much.

Try to avoid sleeve alterations as much as possible. They are a pain to do.

When drawing the curve from the chest (arm hole base) to the waist, don’t draw a smooth curve. Instead, sharply curve inward from the arm hole down about a third of the way, and then go more or less straight to the waistline mark. This is because the waistline circumference is about the body circumference all the way up to the base of the chest.

When measuring how much to take in, turn the shirt inside-out and draw lines from the stitching line that will not be opened up (see below). Most of the time, this will mean drawing the altered lines on the inside back of the shirt, measuring from the farther seam on the sides.

Preparing for Sewing

Unstitch only the stitching line that opens up the flat-felled seam from the inside. (That is, turn the shirt inside-out and unstitch only the line closer to the fold.) This will save the trouble of having to re-align the fabric pieces when resewing. This is the case regardless of the method of flat-felling the seam.

Also unstitch the bottom hem.

Sewing the First Line

Sewing the first line is pretty obvious. For shirts where both sewing lines on each side are chain stitches, it may be necessary to open up a small amount of both sewing lines at the point where the new line will intersect the old one.

Ideally, the first new stitching line should go up to and abut the existing stitching line.

Cutting the Fabric

Try the shirt on before cutting! And keep in mind that flat-felling the seams will make the shirt a little tighter.

Remember to consider which edge is being folded over before cutting.

At the point of cutting, the original seam that was not removed can now be removed. Usually it has to be taken out, because the new seam allowance might go over the existing seam.

At the arm hole seam, cut the edge to be folded over generously, to account for the difficulty of folding over all the extra fabric. This is particularly true for thicker materials.

Sewing the Second Line

So I previously wrote about my difficulties with the Linux Libertine font in PDF files being displayed by the PDF.js viewer. The brief overview is this: PDF files using the Linux Libertine font, as compiled by XeTeX on OS X and displayed in PDF.js via Firefox, will have ligatures show up as various incorrect characters, based on where the ligatures were slotted in the original font’s table of characters. I fixed the problem by renaming the ligature glyphs.

However, this technique led to a problem: text using ligatures could no longer be text-searched or copied. This is because PDF files ordinarily record how to decompose ligatures into individual characters, in a table stored in the PDF file called ToUnicode. With the original glyph names, the ToUnicode table was generated correctly, but when I renamed them they no longer showed up in the table.

It was strange that they were not showing up in the table. One would think that XeTeX would be able to determine the composition of ligatures, since each font contains data indicating how individual characters are aggregated into a ligature. So it would seem logical that the ToUnicode table would simply be a translation of the font’s ligature data. This turned out not to be the case.

As I explained in the previous post, the ligature glyphs were originally named as the individual characters, separated by underscores. So the “ffl” ligature would have been named “f_f_l” in the font. This is based on an Adobe convention, that specifies that ligatures should be named for their component characters, separated by underscores.

Surprisingly, XeTeX (or whatever PDF-generating library it uses) actually relies on that convention: instead of using the ligature data in the font to generate the ToUnicode table, it actually uses the underscore-separated name. So, for example, if I renamed the “ffl” ligature to “X_Y_Z” and generated a PDF with the word “waffles” in it, then copying that word would place in the clipboard the text “waXYZes.”

This meant that I was back at square one: if I put the underscores in the ligature names, then PDF.js would display characters incorrectly, but if I used different names, then searching and copy-paste would not work. So I needed a different solution.

Remember how I said that the incorrectly displayed characters were based on the position where the ligatures were slotted in the font? It occurred to me that, if I changed the slots for the ligatures, then I could possibly change the results and potentially even solve the problem. Looking at some other fonts suggested this was the right track: those fonts placed ligatures around the 300th characters in the font, while Linux Libertine placed the ligatures at about position 3000.

So I just moved the ligatures into approximately slot 300 and up. And it worked!

Here is the updated script that will convert the fonts, again using ttx.

I am generating PDF files using the Linux Libertine fonts and XeTeX. When I view the files with an ordinary PDF reader, they appear fine. However, when I open them with the PDF.js viewer built into Firefox, the ligatures appear as odd foreign characters.

This problem appears to be known, as it is discussed in this bug report. However, there does not appear to be much progress in that thread as to solving it. I haven’t exactly pinned down the problem, but I did at least find a workaround.

The bug is incredibly specific (though, thankfully, easily reproducible). It only occurs when I compile a document on OS X and view the document in the PDF.js viewer on OS X and Firefox. The bug does not show up in any of these situations as I’ve tested:

Compiling the document on Linux

Viewing the document in Firefox on Windows

Viewing the document on PDF.js in Safari on a Mac

The mistake characters seem to be a result of the PDF font subsetting algorithm. On Linux, when the fonts are subsetted, the encoding slots continue to match the original font (and also the Unicode code points, since the fonts are encoded consistent with Unicode). On OS X, however, the encoding slots for the subsetted fonts equal the slots for the original font ignoring unused slots. This means that glyphs far down in the font—ligatures, for example—end up with assigned slots numerically far less than their Unicode code points. And the erroneously displayed glyphs appear to be for characters corresponding to the reassigned slots.

As an example: the “Th” ligature is Unicode code point 0xe049. However, in the Linux Libertine Roman font, it is the 0x095f’th glyph listed, not counting blank slots. Unicode character 0x095f is Devanagari character Yya: य़. And that is the wrongly displayed character shown on the bug report in the place of the “Th” of the word “The.”

Strangely, though, the problem appears only to affect ligatures. The Linux Libertine character at Unicode 0x0e42 is the 0x0958’th glyph, only a few slots away from the problematic Th ligature. There is also a Devanagari character at that position, but PDF.js displays the Linux Libertine character fine.

After some testing, I discovered that simply changing the glyph names for the ligatures would solve the problem. The ligatures in Linux Libertine are named with underscores between letters (e.g., f_f_i or T_h). Merely deleting the underscores corrected the problem entirely. It’s not clear why that is so, but I have noticed that OS X seems to have some special cases for handling ligature characters, and perhaps that is related.

The following Perl script will automatically change the names of glyphs in the fonts to be correct:

To run, paste the above contents into a file, make it executable, and run it with the arguments being all the OTF files for the Linux Libertine fonts. The program will create three new directories for you; the one called “new-otf” is the one of interest. That folder will contain the new, corrected font files.

I hope that someone actually determines the source of this bug, rather than relying on this admittedly hackish solution.

I’ve been using the Linux Libertine fonts with XeTeX for several months now, and while they look beautiful, they for some reason tend to trigger odd quirks about just about every aspect of the typesetting system. One that I’ve been dealing with: the font comes in regular, semibold, and bold weights, but by default XeTeX will use the semibold rather than the bold variant. This is apparently a known issue.

It’s easy enough to fix this by simply specifying the exact bold font to use, say through the fontspec package:

\setmainfont[BoldFont=* Bold]{Linux Libertine O}

But why does XeTeX select the semibold variant by default? I found the answer by looking through the source code of XeTeX, which contains the following code in the file XeTeXFontMgr.cpp:

The background information is that each font in a family is assigned a “weight number,” which determines how bold the font is. So based on the second-to-last line of code above, XeTeX’s algorithm for selecting the bold font is as follows:

Determine the weight of the regular font, and the maximum and minimum weights of the family.

Compute a new bold weight, equal to the regular font’s weight plus half the difference between the family’s maximum and minimum weights (plus a small number to favor rounding up).

Find the font closest in weight to that computed bold weight.

For Linux Libertine, the regular font has weight 400, the semibold 600, and the bold 700. So the computation would go as follows:

Regular weight = 400; maximum weight = 700; minimum weight = 400.

New bold weight = 400 + (700 – 400) / 2 + 1 = 551

Closest font is semibold, at 600

This algorithm strikes me as a bit odd, since it would result in selecting a more bold font if there is a lighter-than-regular font in the family. In any event, this seems to be how it works.

The court document filing system ECF requires Java 1.6 to be installed. This is not the latest version of Java, because apparently there is a bug that prevents the latest Java from working with the system.

To install Java on a Mac running any new version of OS X, you will need to do the following:

Install the latest OS X Java update (the 2014-001 update is here). You will note from the release notes that this will uninstall the web plugin (intended to make room for installation of the newer Java version).

Follow the directions on this page, to reenable the plugin. Briefly, you will need to run four commands from a terminal:

Say you are me and you are updating your MySQL configuration. Say that, for purposes of backup and version control, you replace /etc/mysql/my.cnf with a symlink. Say you stop MySQL and start it up again, and you receive a failure message.

You might venture to look at the service startup log file, perhaps /var/log/upstart/mysql.log. You might discover this error message:

Fatal error: Please read “Security” section of the manual to find out how to run mysqld as root!

You might, if you were me, spend several hours fruitlessly reading that manual and altering parts of the configuration files willy-nilly, to no avail.

At some point, you might become frustrated and just search for that error message, say on Google. That actually wouldn’t help much, because everyone else receiving the error appears to be receiving it for a different reason.

Eventually, you might guess that the symlinking caused the problem, and you would revert that step. And then MySQL would start to work.

This might be enough to satisfy you, but say you want to know exactly why. You might do another Google search, and come across a page entitled MySQL Not Reading Symlinks for Options Files my.cnf. You might be surprised to find that the symlink strategy fails because MySQL is run using AppArmor, and AppArmor is blocking MySQL from reading the symlinked file.

So you might edit the AppArmor configuration files to allow for access to the symlinked configuration file, and you might find that the error goes away.

Also, say you noticed that, for MySQL, there is both an upstart configuration file and a System V init.d file. You might wonder why both are included in the MySQL distribution. Luckily, you would quickly find that the System V file is not in any of the rc*.d directories, so it is never executed.

The network firewall system used in Linux is called iptables. This is a brief overview of the system to the extent that I need to understand it if I want to fix my current firewall setup.

IPTables System Structure

IPTables is made up of a database of network packet processing rules, and an engine that executes the rules as network packets flow through the computer. The database is made up of four tables, each of which handles a different stage of packet processing. Each table includes several chains, some of which are predefined for each table and some of which are created by the user. Each chain has a name and a number of processing rules.

Tables

There are four tables. The difference between each is the types of actions that the tables can take when processing a packet, and the stage at which the rules execution engine invokes the chains of the table.

raw: Rules in this table serves only to turn on or off the “connection tracking” feature (in which iptables can determine, for any given packet, whether it is part of an established TCP connection).

mangle: Rules in this table can manipulate some of the TCP header information in a packet, such as TOS or TTL.

nat: Rules in this table can modify the sender/recipient addresses (for example, so that the computer can act as a router).

filter: Rules in this table can drop or reject packets, among other things.

The filter table is, by far, the most important in terms of setting up a firewall.

Chains

Each table is made up of several chains, each of which contains a sequential list of rules. The execution engine “executes” a chain for a given packet by applying each of the chain’s rules to the packet in sequence. Some of these chains are predefined, and those chains are executed at appropriate times during packet processing, as explained in the table below. Other chains are user-defined, and they are executed when called from another chain (somewhat like subroutines).

Chain

When Executed

Which Chains

PREROUTING

Upon receiving a packet at a network interface

All chains

OUTPUT

Upon receiving a packet from a local process

All chains

INPUT

Upon receiving a packet at a network interface, after determining that it is being directed to a local process

mangle, filter

FORWARD

Upon receiving a packet at a network interface, after determining that it is directed to another computer

mangle, filter

POSTROUTING

Immediately before sending a packet out of a network interface

mangle, nat

For each of the predefined chains above, the raw table chain is always executed first, followed by the mangle, nat, and finally filter tables. PREROUTING is always done before INPUT or FILTER, and POSTROUTING is always done after OUTPUT or FILTER.

Rules

A rule is made up of two parts: a matching condition and a target. When the execution engine applies a rule to a packet, it checks whether the packet satisfies the matching condition of the rule, and if so, then it performs an action defined by the target.

The matching conditions are tests of various parts of the packet header and content, such as source and destination addresses and ports. The possible matching conditions are described below in the discussion of the iptables command.

The target may be one of two types: a predefined target, which performs an action internally defined by iptables, and a jump to another chain. Predefined targets may specify changes to packet contents, direct the execution engine to accept or drop a packet, or control the flow of rules execution. Some predefined targets may halt further execution of rules. Some particular predefined targets are described below in the discussion of the iptables command.

In the case of a jump, the execution engine proceeds to execute the other chain. Assuming that execution is not halted after that other chain is executed, the engine returns to the chain from which the jump was made, and execution of the calling chain proceeds with the next rule.

As a catch-all, each predefined chain has a default target, called a policy. The default target must be a predefined target.

Command-Line Management of Rules

Rules in iptables are managed with the iptables command. It must be run as the root user.

The iptables command line interface is entirely driven by command-line options. At least one option must be specified: the option identifying the operation to be performed. The various operations are described below.

Every invocation of iptables can accept the -t option to select the table to manipulate. By default, the filter table is used. Many commands also use a rule-specification, which describes a complete rule including matching condition and target. The syntax of a rule-specification is described after the listing of operations.

Operations Managing Chains

-N [chain-name]: create a new user-defined chain in the specified table.

-X [chain-name]: delete a user-defined chain from the specified table. The chain must have no rules and not be the destination of any jump.

-F [chain-name]: delete all of the rules in a chain.

-P [chain-name] [target]: set the policy for a chain.

Operations for Displaying Chains

-L [chain-name]: list all the rules in a chain (or all chains, if none is specified). The -v option will add packet and byte counts.

-S [chain-name]: list all the rules in a chain, in a different format.

Operations for Managing Rules in a Chain

-A [chain] [rule-specification]: append a rule to the end of a chain.

-C [chain] [rule-specification]: check to see that a rule matching the given rule specification is present in the chain.

-D [chain] [rule-specification]: delete a rule matching the given specification, from the chain.

-D [chain] [rule-number]: delete a rule from the chain based on the rule’s position in the chain, where the first rule is 1.

-I [chain] [rule-number] [rule-specification]: insert a rule above the specified position in the chain (so rule number 1 would place the rule at the top of the chain).

Rule Specifications: Matching Conditions

Matching conditions of rule specifications are made up of key-value pairs, with the keys specified as command-line options and the values as arguments to the options. Some of the more common ones are as follows:

-p [protocol]: the packet’s protocol must be of the specified type (e.g., tcp).

-s [addresses]: the source address of the packet must match one of the given addresses (a list of addresses, possibly with CIDR masks, separated by commas).

-d [addresses]: the destination address of the packet must match one of the given addresses.

Further matching conditions can be introduced through the match extensions mechanism. First, an appropriate module must be loaded through the -m [module] option. (As a convenience, specifying a protocol with -p automatically loads a module with the same name.) Then, all of the matching conditions of the module become available.

The most common of these are the --destination-port options of the tcp module, and the analogous (pluralized) options of the multiport module.

Rule Specifications: Targets

Targets are also specified as key-value pairs expressed as command-line options. One option must always be included: the -j [target] (for jump) option, specifying the name of the user-defined chain or predefined target. Some of the predefined targets require further options as well.

A partial listing of predefined targets is below:

ACCEPT: allow the packet through, and terminate execution of all rules.

DROP: drop the packet, and terminate execution of all rules.

REJECT: drop the packet, send an ICMP reply, and terminate execution. This is preferred over DROP because, to a port scanner, it looks the same as a closed port.