Philipp Schmid

Lets revive this :)

Mon, 13 Jan 2020 00:00:00 +0100

At least I hope this won’t stay empty for another four years…

Btw, the Lancia is still not finished. It was a much worse buy than originally thought.

I bought another one btw, this Honda Accord SJ 81 will stay in Bremen:

Also I witnessed this amazing firework in north korea:

just posting random stuff for fun…

View this post on Instagram

20xx printrbot vs ultimaker 2+ #ultimaker #3dprinting

A post shared by Philipp Schmid (@schmidphilipp) on Jan 12, 2020 at 4:19pm PST

Lancia Fulvia Sport (Zagato) 1600

Mon, 18 Apr 2016 00:00:00 +0200

I cannot really remember why I got interested in old cars - I do remember always admiring Tim Taylor from Home Improvement, for slowly building up his Hot Rod.

But what specifically got me to buy myself a classic car book and price index (Oldtimer Katalog Nr. 30: Europas größter Marktführer - Jubiläumsausgabe 30 Jahre) slipped my mind.

Anyway, I went thought the book and looked for cars that have an interesting style, are not yet extremely expensive and have some kind of interesting history. The car that stood out in the end was the Lancia Fulvia Zagato.

Car #1 Vienna

So I started looking for those cars and there was even one 1972 1.6 being sold near Vienna for € 24500 at Jüly Oldie Point. Lena and I had a look at the car on a weekend sometime in 2015, it was a red 1.6 liter one. Lancia only built 800 of them.

But the car was in a condition, that I didn’t have the guts to buy it:

Broken windscreen
Doors did not close
Carburates where removed and seemed to have burned
Lot’s of other things I don’t rembember

Car #2 Amsterdam

Then I looked at a car in Amsterdam. The seller wanted € 30000 when I first saw the car online (maybe early 2015?) and € 35000 in November 2015:

I did not buy the car (the last price was € 33000), because I was hoping to find one in better condition and maybe even cheaper directly in italy.

Car #3 Milano

So the next stop was Milano in Italy. I wanted to look at this car (which is currently still available): http://ww3.autoscout24.at/classified/274848683, so Lena and I flew to Milano over the weekend to also do some sight seeing.

By chance, there also was the Milano Classic Expo on the same weekend, where Lena and I went to on Saturday morning. Lots of great cars :-) We even saw (and heared!) a Lancia Stratos racing around a track.

At the expo, I also saw my orange Zagato for the first time, but more about that later.

So we left the expo to look at the red Zagato:

The owner was a private seller (a lawyer) and very nice, he picked us up from the hotel and showed us the car. He wanted € 40000, but I felt that the Zagato at the Expo was in better shape and much cheaper. So I offered him a much, much lower price, which he (as I expected) did not acccept.

Car #4 Milano

As already mentioned, at the Milano Classic Car expo, there was an orange Zagato for sale by a dealer (Grimaldi in Vigevano).

Here are some pictures of the car at the expo:

After the weekend in Milano I was back in Vienna and there was still no Zagato in my driveway :-/

Luckily, two weeks later I had a business trip to Milano and used the time to look at the orange one again. I took a test drive and inspected the car for 2 hours:

the engine was hot when I came there, but was running very nice otherwise
some coolant was leaking from a tube, nothing major
bumpers have quite a few dents
the dashboard is cracked not particularly nice
speedometer does not work
the door handles feel loose and they do not lock well.
some rust at the rear hatch, but overall I could’t find much rust

But, from my limited knowlege, the car looked pretty complete.

So I pulled the trigger and made the dealer an offer that included transporting the car to Vienna. He accepted, we shook hands and I was the owner of a 44 year old car.

According to the dealer, the story of the car is: A guy bought it 20 years ago and restored it. Shortly afterwards he had a fatal car accident and the car stayed in his garage until his wife sold it to the dealer.

About two weeks later the dealer sent me a picture of the car being loaded onto a trailer:

So on the 15th of April my Lancia Fulvia Zagato 1600 818.750 001490 finally arrived at his new home:

Full Disk Encryption with GRUB 2 + LUKS + LVM + SWRAID on Debian Jessie

Fri, 12 Dec 2014 00:00:00 +0100

In January I started setting up a home server/NAS based on FreeBSD on a HP Microserver. Read about my setup in part 1 and part 2.

While I generally like the idea (BSD license, complete base system in one repo) and community behind FreeBSD, I have the feeling that the project is missing some manpower. VIMAGE is still experimental and in combination with PF it will crash every night (because of a Cron job). There seems to be a bug that IPSec tunnels bypass the firewall. There is no AMD support in bhyve yet (it’s scheduled for October 2014 with the 10.1 release), so I cannot run any virtual machines on my home server.

So my concerns about manpower and the fact that I cannot run any virtual machines yet lead me back to Debian Linux.

The Plan

Because with Debian I can use KVM and run multiple virtual machines, I’ll set up a minimalistic, fully encrypted base system with Debian. All services the NAS will supply will run in virtual machines that run Ubuntu, Debian or FreeBSD.

The Setup

Before we finally talk about the setup, I’d like to give attribution to the blog posts that I based this guide on:

Hardware

I have four disks in my HP MicroServer:

Disk 1: Operating System - 3.5’ 250GB 7200RPM HDD
Disk 2: Operating System - 2.5’ 200GB 7200RPM HDD
Disk 3: Data - 3.5’ 4TB NAS HDD
Disk 4: Data - 3.5’ 4TB NAS HDD

The first two disks will hold the base operating system and maybe the virtual machine operating system images. The data disks will be for data only.

The storage system layers will look like this:

| Filesystem (eg. ext4) |
| LVM                   |
| LUKS Crypto           |
| Linux Software RAID 1 |
| Physical Hard Disk    |

Above the physical block layer, we’ll put a Linux software RAID. The first RAID 1 will span disks 1 and 2 and a second RAID 1 will span the data disks (disks 3 and 4).

And on top of the software RAID will be the encryption layer. Why not the other way round? Because otherwise we would have two crypto devices instead of one, and the CPU would have to encrypt/decrypt any write/read operation twice.

This thread on the dm-crypt list discusses the two options.

Software

We are going to use grml, a Debian-based rescue/admin live distribution, to install the system.

So after downloading grml and booting the live CD, let’s start with becoming root:

sudo su -

Initialize the disks with random data

We will start writing random data to the two operating system disks.

badblocks -c 10240 -w -t random -s -v /dev/sda
badblocks -c 10240 -w -t random -s -v /dev/sdb

This may take a very long time, depending on how big your disks are.

Partitioning the OS disks

root@grml ~ # parted /dev/sda
GNU Parted 2.3
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) mklabel gpt                                                      
(parted) mkpart primary 2048s 4095s
(parted) set 1 bios_grub on                                               
(parted) name 1 "BIOS Boot Partition"                                     
(parted) mkpart primary 4096s 100%                                        
(parted) set 2 raid on
(parted) name 2 "SW-RAID / Linux"                                         
(parted) quit                                                             
Information: You may need to update /etc/fstab.

Copy the the partition table from the first disk to the second:

root@grml ~ # sgdisk -R=/dev/sdb /dev/sda
The operation has completed successfully.

Set new UUIDs on /dev/sdb:

root@grml ~ # sgdisk -G /dev/sdb
The operation has completed successfully.

RAID Mirror Setup

root@grml ~ # mdadm --create /dev/md0 --verbose --level=mirror --raid-devices=2 /dev/sda2 /dev/sdb2
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
mdadm: size set to 10474496K
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

LUKS Crypto Setup

We use aes-xts as XTS works especially well for encrypting filesystems.
The keysize of 512 is actually 256, because XTS splits the key in half.
Because we use sha512 instead of sha1, we need to increase the time for the hash iterations.
Also, we have to use /dev/random instead of /dev/urandom, as urandom does not stop giving data if entropy gets low.

cryptsetup -v --cipher aes-xts-plain64 --key-size 512 --hash sha512 --iter-time 5000 --use-random --verify-passphrase luksFormat /dev/md0

Now let’s open the crypto device:

cryptsetup luksOpen /dev/md0 cryptomd0

LVM Setup

Let’s create a physical volume and a volume group:

root@grml ~ # pvcreate /dev/mapper/cryptomd0
  Physical volume "/dev/mapper/cryptomd0" successfully created
root@grml ~ # vgcreate system /dev/mapper/cryptomd0
  Volume group "system" successfully created

Now the logical volumes. Be sure to ajust the sizes of the volumes to fit your system:

root@grml ~ # lvcreate -n swap -L1G system
  Logical volume "swap" created
root@grml ~ # lvcreate -n root -L6G system
  Logical volume "root" created

Create the file systems

root@grml ~ # mkfs.ext4 /dev/system/root
mke2fs 1.42.9 (4-Feb-2014)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
393216 inodes, 1572864 blocks
78643 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1610612736
48 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
  32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

root@grml ~ # mkswap -f /dev/system/swap
Setting up swapspace version 1, size = 1048572 KiB
no label, UUID=a44ea90d-72b4-4d2c-864f-70e9d2218651

Preparing for installation

root@grml ~ # mkdir /mnt/root
root@grml ~ # mount /dev/system/root /mnt/root

Installation

grml-debootstrap --target /mnt/root --password YOUR_PASSWORD --hostname YOUR_HOSTNAME --release jessie

Finishing the installation

Let’s get into our new installation:

root@grml ~ # grml-chroot /mnt/root /bin/bash
Writing /etc/debian_chroot ...
(YOUR_HOSTNAME)root@grml:/#

(rna)root@grml:~# apt-get install console-setup

Edit /etc/fstab to look like:

/dev/system/root  / auto    defaults,errors=remount-ro  0 1
/dev/system/swap  none  swap    sw                      0 0
proc      /proc proc    defaults                        0 0

Edit /etc/crypttab to look like:

cryptomd0 /dev/md0 none luks

(YOUR_HOSTNAME)root@grml:~# echo GRUB_CRYPTODISK_ENABLE=y >> /etc/default/grub
(YOUR_HOSTNAME)root@grml:~# echo 'GRUB_PRELOAD_MODULES="lvm cryptodisk mdraid1x"' >> /etc/default/grub

(YOUR_HOSTNAME)root@grml:/# grub-install /dev/sda
Installation finished. No error reported.
(YOUR_HOSTNAME)root@grml:/# grub-install /dev/sdb
Installation finished. No error reported.

(YOUR_HOSTNAME)root@grml:/# update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-3.14-1-amd64
df: Warning: cannot read table of mounted file systems
(YOUR_HOSTNAME)root@grml:~# update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-3.14-1-amd64
Found initrd image: /boot/initrd.img-3.14-1-amd64
done

Prepare for reboot

(YOUR_HOSTNAME)root@grml:~# exit
exit
grml-chroot /mnt/root /bin/bash  9.21s user 2.43s system 0% cpu 21:20.00 total
root@grml ~ # umount /mnt/root

Reboot

root@grml ~ # reboot

Book List September 2014

Fri, 10 Oct 2014 00:00:00 +0200

Books I read in September:

The Lean Startup by Eric Ries

Notes

Building a startup is an exercise in institution building; thus, it necessarily involves management.

The Lean Startup method, in contrast, is designed to teach you how to drive a startup. Instead of marking complex plans that are based on a lot of assumptions, you can make constant adjustments with a steering wheel called the Build-Measure-Learn feedback loop.

A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.

Lean thinking defines value as providing benefit to the customer; anything else is waste.

I’ve come to believe that learning is the essential unit of progress for startups.

This is true startup productivity: Systematically figuring out the right things to build.

The two most important assumptions entrepreneurs make are what I call the value hypotheses and the growth hypotheses. The value hypotheses tests weather a product or service really delivers value to customers once they are using it. For the growth hypotheses, which tests how new customers will discover a product or service, …

Their [entrepreneurs and managers] challenge is to overcome the prevailing management thinking that puts its faith in well-researched plans. Remember, planning is a tool that only works in the presence of a long and stable operating history.

Build-Measure-Learn Feedback Loop: LEARN -> Ideas -> BUILD -> Product -> MEASURE -> Data -> LEARN

… we need to focus our energies on minimising the total time through this feedback loop. This is the essence of steering a startup…

[To implemented validated learning] … the method I recommend is called innovation accounting, a quantitive approach that allows us to see whether our engine-tuning efforts are bearing fruit. It also allows us to create learning milestones.

Finally, and most important, there’s the pivot. Upon completing the Build-Measure-Learn loop, we confront the most difficult question any entrepreneur faces: whether to pivot the original strategy or persevere.

Although we write the feedback loop as Build-Measure-Learn because the activities happen in that order, our planning really works in the reverse order: we figure out what we need to learn, use innovation accounting to figure out what we need to measure to know if we are gaining validated learning, and then figure out what product we need to build to run that experiment and get that measurement.

The first challenge and entrepreneur is to build an organisation that can test these [basically all, business assumptions, strategy assumptions, assumptions about customer acceptance.] assumptions systematically. The second challenge, as in all entrepreneurial situations, is to perform that rigorous testing without losing sight of the company’s overall vision.

The restated approach should make clear that what is needed is to do some empirical testing first: let’s make sure that there really are hungry customers out there eager to embrace our new technology.

There are many value-destroying kinds of growth that should be avoided. An example would be a business that grows through continuous fund-raising from investors and logs of paid advertising but does not develop a value-creating product.

The importance of basing strategic decisions on firsthand understanding of customers is one of the core principles that underlies the Toyota Production System. At Toyota, this goes by the Japanese term genchi gembutsu, which is one of the most important phrases in the lean manufacturing vocabulary. In English, it is usually translated as a directive to “go and see for yourself” so that business decisions can be based on deep firsthand knowledge.

Before new products can be sold successfully to the mass market, they have to be sold to early adopters. These people are a special breed of customer. They accept - in fact prefer - an 80 percent solution; you don’t need a perfect solution to capture their interest.

Early adopters use their imagination to fill in what a product is missing. They prefer that state of affairs, because what they care about above all is being the first to use or adopt a new product or technology. In consumer products, it’s often the thrill of being the first one on the block to show off a new basketball shoe, music player, or cool phone. In enterprise products, it’s often about gaining a competitive advantage by taking a risk with something new that competitors don’t have yet. Early adopters are suspicious of something that is too polished: if it’s already for everyone to adopt, how much advantage can one get by being early? As a result, additional features or polish beyond what early adopters demand is a form of wasted resources and time.

It is important to contrast this with the case of a small business, in which it is routine to see the CEO, founder, president, and owner serving customers directly, one at a time. In a concierge MVP, this personalised service is not the product but a learning activity designed to test the leap-of-faith assumptions in the company’s growth model.

In a Wizard of Oz test, customers believe they are interacting with the actual product, but behind the scenes human beings are doing the work.

If we do not know who the customers is, we do not know what quality is.

Customers don’t care how much time something takes to build. They care only if it serves their needs.

As you consider building your own minimum viable product, let this simple rule suffice: remove any feature, process, or effort that does not contribute directly to the learning you seek.

For startups that rely on patent protection, there are special challenges with releasing an early product. [so read up on them]

In fact, I have often given entrepreneurs fearful of this issue the following assignment: take one of your ideas (one of your lesser insights, perhaps), find the name of the relevant product manager at an established company who has responsibility for that area, and try to get that company to steal your idea. Call them up, write them a memo, send them a press release - go ahead, try it. The truth is that most managers in most companies are already overwhelmed with good ideas. Their challenge lies in prioritisation and execution, and it is those challenges that give a startup hope of surviving.

The only way to win is to learn faster than anyone else.

Successful entrepreneurs do not give up at the first sign of trouble, nor do they preserve the plane right into the ground. Instead, they possess unique combination of perseverance and flexibility.

We all need a disciplined, systematic approach to figuring out if we’re making progress and discovering if we’re actually achieving validated learning.

This is why to myth of perseverance is so dangerous. We all know stories of epic entrepreneurs who managed to pull out a victory when things seemed incredibly bleak. Unfortunately, we don’t hear stories about the countless nameless others who preserved too long, leading their companies to failure.

When one is choosing among the many assumptions in a business plan, it makes sense to test the riskiest assumptions first.

To demonstrate validated learning, the design changes must improve the activation rate of new customers. If they do not, the new design should be judged a failure. This is an important rule: a good design is one that changes customer behaviour for the better.

Compared to a lot of startups, the Grockit team had a huge advantage: they were tremendously disciplined. A disciplined team may apply the wrong methodology but can shift gears quickly once it discovers its error. Most important, a disciplined team can experiment with its own working style and draw meaning ful conclusions.

.. the three A’s of metrics. actionable, accessible, and auditable.

In Silicon Valley, we call this experience getting stuck in the land of the living dead. It happens when a company has achieved a modicum of success - just enough to stay alive - but is not living up to the expectations of its founders and investors. Such companies are a terrible drain of human energy. Out of loyalty, the employees and founders don’t want to give in; they feel the success might be just around the corner.

We’ve discussed the telltale signs of the need to pivot: the decreasing effectiveness of product experiments and the general feeling that the product development should be more productive. Whenever you see those symptoms, consider a pivot.

I recommend that every startup have a regular “pivot or preserve” meeting. In my experience, less than a few weeks between meetings is too often and more than a few months is too infrequent.

Working in small batches ensures that a startup can minimise the expenditure of time, money, and effort that ultimately turns out to have been wasted.

Five Whys is a powerful organisational technique. Some of the engineers I have trained to use it believe that you can derive all the other Lean Startup techniques from the Five Whys. Coupled with working in small batches, it provides the foundation a company needs to respond quickly to problems as they appear, without overinvesting or overengineering.

I ask teams to adopt these simple rules:

Be tolerant of all mistakes the first first time
Never allow the same mistake to be made twice

As Lean Startups grow, they can use adaptive techniques to develop more complex processes without giving up their core advantage: speed through the Build-Measure-Learn feedback loop. In fact, one of the primary benefits of using techniques that are derived from lean manufacturing is that Lean Startups, when they grow up, are well positioned to develop operational excellence based on lean principles. They already know how to operate with discipline, develop processes that are tailor-made to their situation, and use lean techniques such as the Five Whys and small batches.

… startup teams require three structural attributes: scarce but secure resources, independent authority to develop their business, and a personal stake in the outcome.

Shusa … Toyota employees translate the term as chief engineer, and they refer to the vehicle under development as the shusa’s car. They assured us that the shush has final, absolute authority over every aspect of vehicle development.

There is a fourth phase as well, one dominated by operating costs and legacy products. This is the domain of outsourcing, automation and cost reduction.

Over time, those teams are almost guaranteed to improve as long as they get the constant feedback of small-batch development and actionable metrics and are held accountable to learning milestones.

Notes on: Sam Altman's How to Start a Startup - Lecture 2

Sat, 27 Sep 2014 00:00:00 +0200

Y Combinator teaches a class at Stanford on startups: http://startupclass.samaltman.com

These are my notes on Lecture 2:

Ideas, Products, Teams and Execution Part II

Q&A on Lecture 1

How to identify markets that are growing quickly:

Trust your instincts. Younger people/students have an advantage. Just watch what you and others are doing.

How to deal with burnout as a founder:

It sucks, but you just have to keep going. Address the things that are going wrong . . .

Lecture 2

Co-Founders

The co-founder relationship is very, very important – one of the most important decisions. The track record for companies whose founders don’t know each other well is very bad.

A solo founder is better than a random co-founder.

A founder should be relentlessly resourceful. A founder’s role model should be James Bond (really!). You need someone who behaves like James Bond.

You want to have known your co-founders for years.

You want a tough, calm co-founder.

Two or three co-founders work well. Five are really bad.

When should co-founders decide on the equity split? Very soon after they start working together. It should be near equal.

You have to discuss what happens when a co-founder leaves. Shares should vest over four years. Anyone who leaves within the first year gets nothing.

Co-founders should be in the same location. Sam is very skeptical about remote teams in general.

Team

Try not to hire! Be proud to have as few employees as possible.

The most successful YC companies have no or very few employees. In the early days, the goal should be not to hire.

The cost of getting an early hire wrong is very high. It usually kills the company.

Write down a list of core values a hire should have. Most importantly, he should love the product. (Would you still want to work on our project if you got a medical diagnosis that you had only one year left to live?)

Have a very high bar. Get the best people.

It can easily take a year to recruit someone very good.

How much time should you spend on hiring? Either 0 or 25% of your time.

Mediocre engineers do not build great companies. Mediocre engineers infect the culture of a startup and destroy it.

The best people to hire are people you or your coworkers already know.

For most early hires in a startup experience does not help very much, but appetite does.

What to look at:

Are they smart?
Do they get things done?
Do I want to spend a lot of time around them?

Call references. Dig in. Is this person in the top 5%? Why don’t you try to hire this person again?

Good communication skills
Maniacally determined (they should also like risk)
Pass the “animal test” (see Paul Graham )
You would feel comfortable reporting to them

Care more about giving equity to employees than investors. Be generous with equity to early employees.

After you hire someone, you have to retain them. They have to feel happy and valued.

Praise your team. Give your team credit for all the good that happens. You take responsibility for the bad things.

Fire fast. It’s better for the company, it’s better for the employee.

Execution

Whatever the founders do becomes the culture. The founders have to be execution machines.

Ideas themselves are not worth anything without someone executing them.

The CEO has five jobs:

Set the vision
Raise money
Evangelize the company
Hire and manage
Make sure the entire company executes

Execution: Can you figure out what to do? You get it done.

Focus

Focus. Identify the most important two or three things and work on them. Ignore or delegate the others. If you don’t, you will never be great about getting stuff done.

Many startups/founders work really hard, but they work on the wrong things. If you work really hard on the wrong things, nobody will care.

Communicate the goals. This keeps the company focused and everyone works in the right direction. Communicate them over and over again.

Focus on growth and momentum. Have metrics for this. If you don’t focus on these two things, you are probably doing it wrong.

Intensity

You have to outwork your competitors.

Relentless operating rhythm (move fast and break things)
Obsession with execution quality

You need to move fast, but maintain high quality (of course it’s tricky)

Bias towards action: you need to make decisions.

The best founders are:

Quick: they respond to email quickly . . .
Present: they show up at meetings . . .

Always keep momentum. Never take your foot off the gas peddle. A winning team keeps winning. A losing team gets demotivated and keeps losing.

Software startups: always keep growing.

Hardware startups: don’t miss shipping dates.

Getting the product right in the beginning is the best way to avoid losing momentum later.

If you have a demotivated team, you have to find small wins. “Sales fix everything.”

Don’t worry about competitors unless they beat you with a real, shipped product. Don’t give a shit about press releases.

Don’t spend more money than you have.

Notes on: Sam Altman's How to Start a Startup - Lecture 1

Thu, 25 Sep 2014 00:00:00 +0200

Y Combinator teaches a class at Stanford on startups: http://startupclass.samaltman.com

These are my notes on Lecture 1:

Welcome, and Ideas, Products, Teams and Execution Part I

The course is for startups that aim for hyper growth.

It covers four areas:

Idea
Product
Team
Execution

Idea

Only start a company if you want to fix a specific problem, not for the sake of the startup itself. The problem comes first, the startup second.

Long-term thinking is extremely important – 10 years.

Build a business that is difficult to replicate.

The idea comes first. A good idea is extremely important.

Have a mission-oriented idea. People need a mission to be really good at something.

Good startups take 10 years.

Copying an existing idea is nothing that gets people excited.

Ideas that seem bad at first are often very good. If it sounded really good, everybody would do it.

Find a niche where you can create a monopoly and expand from that.

The initial idea does not have to sound big, but it has to take a big market share of a specific niche.

Think about the growth rate of the market.

Ask yourself the question: Why now? Why was two years ago too early? Why will it be too late in two years?

Build something you need yourself; otherwise, you’re at a big disadvantage.

The idea should be very easy to explain. If that is not possible, the idea is too complicated.

Think about the market first – what people want.

Product

Great Idea -> Great Product -> Great Company

Build a good product. Ignore everything else. Build something that users love.

Build something that a small number of users love, instead of building something that a lot of people use, but do not love.

Sales and marketing is very important, but in the early days you need organic growth. If you don’t have it, you just waste your money on sales and marketing.

Very few startups die from competition. Most die because they don’t build something that users love.

Great founders are fanatic about the quality of the product.

Create a very tight feedback loop. Show it -> Feedback -> Product

The use of metrics is super-important:

total registrations
active users
activity levels
cohort retention
revenue
Net Promoter Score

Dustin Moskovitz: Why to Start a Startup

“You Can’t Not Do It.” You are so passionate about it that you have to do it.

When you’re recruiting, candidates can smell if you don’t have passion.

Do something the world needs!

Book List August 2014

Wed, 10 Sep 2014 00:00:00 +0200

Books I read in August:

Software Estimation: Demystifying the Black Art (Developer Best Practices) by Steve McConnell

The book is about software estimation as an art, not a science. It aims to help you get your estimates within a plus/minus 25% range. While 25% still sounds huge, many companies have trouble estimating more precisely than plus/minus 100%, which I can confirm from our own (painful, expensive) experience.

McConnell gives you a framework of estimation techniques that you can use, adapt and combine to improve the estimation skills of your team/organization. We have started to use some very simple techniques from the book and are already feeling much more confident in our estimations.

tl;dr Tighten the Cone of Uncertainty. Count, don’t judge. Use historical data from your own team/organization to estimate size, effort, and schedule.

Buy? Yes

How to organize offshore and nearshore collaboration: Lessons learned in offshoring and nearshoring by Hugo Messer et al.

Notes

Three ingredients for successful remote collaboration:

process
responsibilities
performance (and measuring)

Ensure that the team members discuss their personal development with their manager every 3-6 months.

The product owner should be onshore, as close as possible to the customer.

The whole team is part of sprint planning (via videoconferencing).

Who is responsible for:

Describing the functionality and user stories?
Deciding what to build when in a sprint?
Testing the app?
Demoing the app?

One crucial role in offshore collaboration is a “process manager” (also called a delivery manager, quality manager or similar title). This person’s responsibility lies outside the project, and his core mission is to ensure smooth communication between the onshore and offshore teams.

To lay a solid foundation for remote collaboration, it is important to create “think time” before “doing”.

If your collaboration involves core algorithms or functionality, have good NDAs and grant access on a strict need-to-know basis.

Lack of proper planning makes it impossible to set up the right infrastructure and results in the failure of many projects. Agile development thrives in an environment which promotes collaboration and trust, and the right infrastructure is the key enabler for this.

The audio/video devices from Avaya and Polycom have given me good results in many locations.

Interactive digital whiteboards are cool.

Use a tool that’s able to record both the screen and the audio during conference calls.

CamStudio has a pretty good free screen recording software.

When team members from a different country visit, get volunteers from the onshore part of the same team to accompany them. They can act as local guides for shopping and sightseeing. I have personally experienced strong bonding after such outings.

Set up periodic communication about the project vision, overall project milestones, and key developments.

Use a gated check-in policy (all commits still have to build). Use continuous integration.

Ensure that everyone has a good and current view of the project. Use wikis, dashboards, chats, blogs, and issue tracking.

Continuous integration is a practice which enables early assembly of code units to a common shared mainline, as well as reflection on code quality, unit tests, and other kinds of measurable parameters.

Dashboards on LCD TVs in a project area are a nice way to represent the current build status and compliance reports for the agreed quality indicators.

There is no rule of thumb except that local teams should be able to work independently and that dependencies across teams should be identified and clear. This could mean that roles such as Business Analyst or Technical Architect will have to co-exist with local teams (this was for offshore teams).

We have found that our best practice in nearshoring is to work together as one team rather than subcontracting parts of the work. Modern communication devices and the availability of high bandwidth enables this. We call this an eXtended Resource Team (XRT).

XRT Principles

We are all equal colleagues. We treat every team member as a colleague – not as a replaceable extra resource, but as a long-term colleague.
We are one Team. Both teams can do all activities. In this way we steer away from work packages and are free to distribute the tasks on a day-to-day basis where the availability and capacity are independent of the location.
We have daily contact. Every day, the manager interacts with all the team members. Thus, we make sure that the team stays together and everyone has the same knowledge available to make the right decisions.
We create opportunities together. The team manager visits the nearshore part of the team at least every other month. The whole team gets together at the start of a new project and at least once a year.

tl;dr Use collaboration tools. Build a team. Someone has to be responsible.

Buy? Maybe

How To Get Prepared For Managing A Remote Team by Hugo Messer et al.

Notes

I just started taking notes on my Kindle, so I don’t have many on this book.

Offshore Process

Ambiguities in specification documents will be very expensive. Expect a lack of background understanding of the business processes (of the project or the customer) by your offshore team.

Make sure you have developed a common understanding on the expected deliverables.

Team Room

This is only for working. There should be another room for casual or non-work-related talk.

You need good headsets so you can talk collaboratively without disturbing others.

You need multiple project walls, as well as a company wall.

tl;dr Interesting read for everyone thinking about building a nearshore or offshore team.

Buy? Yes

IPSec between FreeBSD and Mac OS X in Transport Mode

Mon, 20 Jan 2014 00:00:00 +0100

Because I do not trust WPA2 Wifi encryption for sensitive data, I implemented IPSec in transport mode between my NAS and my Mac.

Mac OS X

Open the file containing the pre-shared keys:

sudo vim /etc/racoon/psk.txt

And add the IP adress of the FreeBSD box:

10.0.1.5      password

Add to /etc/racoon/racoon.conf

remote 10.0.1.5 [500]
{
  exchange_mode main;
  doi ipsec_doi;
  situation identity_only;

  my_identifier   address 10.0.1.6;
  peers_identifier        address 10.0.1.5;

  lifetime        time 8 hour;
  passive         off;
  proposal_check  obey;
  generate_policy off;

  proposal {
    encryption_algorithm    aes 256;
    hash_algorithm          sha512;
    authentication_method   pre_shared_key;
    lifetime time           30 sec;
    dh_group                16;
  }
}

# Mac <-> NAS transport
sainfo address 10.0.1.6 any address 10.0.1.5 any {
  pfs_group 16;
  encryption_algorithm aes 256;
  authentication_algorithm hmac_sha512;
  compression_algorithm deflate;
}

/etc/racoon/setkey.conf:

#!/usr/sbin/setkey -f

## Flush the SAD and SPD
#
flush;
spdflush;


# Mac <-> NAS transport
spdadd 10.0.1.6 10.0.1.5 any -P out ipsec esp/transport//require ah/transport//require;
spdadd 10.0.1.5 10.0.1.6 any -P in ipsec esp/transport//require ah/transport//require;

FreeBSD 10

First you need to compile a kernel that supports IPSec. Check the FreeBSD handbook on how to do that.

options         IPSEC
device          crypto
options         IPSEC_FILTERTUNNEL
device          enc

Assuming you are running a kernel that supports IPSec:

cd /usr/ports/security/ipsec-tools
make install

Pre-shared keys:

vim /usr/local/etc/racoon/psk.txt

And add the IP address of the FreeBSD box:

10.0.1.6      password

chmod 0600 /usr/local/etc/racoon/psk.txt

Setup: /usr/local/etc/racoon/racoon.conf:

# search this file for pre_shared_key with various ID keys.
path pre_shared_key "/usr/local/etc/racoon/psk.txt";

# racoon will look for certificate file in the directory,
# if the certificate/certificate request payload is received.
path certificate "/etc/cert" ;

# "padding" defines some parameter of padding.  You should not touch these.
padding
{
  maximum_length 20;      # maximum padding length.
  randomize off;          # enable randomize length.
  strict_check off;       # enable strict check.
  exclusive_tail off;     # extract last one octet.
}

# If no listen directive is specified, racoon will listen to all
# available interface addresses.
listen
{
  isakmp          10.0.1.5 [500];
}

# Specification of default various timer.
timer
{
  # These value can be changed per remote node.
  counter 10;             # maximum trying count to send.
  interval 3 sec; # interval to resend (retransmit)
  persend 1;              # the number of packets per a send.

  # timer for waiting to complete each phase.
  phase1 30 sec;
  phase2 30 sec;
}

remote 10.0.1.6 [500]
{
  exchange_mode   main;
  doi             ipsec_doi;
  situation       identity_only;
  my_identifier   address 10.0.1.5;
  peers_identifier        address 10.0.1.6;
  lifetime        time 8 hour;
  passive         off;
  proposal_check  obey;
  generate_policy off;

    proposal {
      encryption_algorithm    aes 256;
      hash_algorithm          sha512;
      authentication_method   pre_shared_key;
      lifetime time           30 sec;
      dh_group                16;
    }
}

# NAS <-> Mac transport
sainfo address 10.0.1.5 any address 10.0.1.6 any {
  pfs_group 16;
  encryption_algorithm aes 256;
  authentication_algorithm hmac_sha512;
  compression_algorithm deflate;
}

Setup: /usr/local/etc/racoon/setkey.conf:

flush;
spdflush;

# NAS <-> Mac transport
spdadd 10.0.1.5 10.0.1.6 any -P out ipsec esp/transport//require ah/transport//require;
spdadd 10.0.1.6 10.0.1.5 any -P in ipsec esp/transport//require ah/transport//require;

Configure pf rules /etc/pf.conf:

# IPSec
pass in quick proto esp from any to any
pass in quick proto ah from any to any
pass in quick proto ipencap from any to any
pass in quick proto udp from any port=500 to any port=500
pass out quick proto esp from any to any
pass out quick proto ah from any to any
pass out quick proto ipencap from any to any
pass out quick proto udp from any port=500 to any port=500

Add to /etc/rc.conf

# IPSec
ipsec_enable="YES"
ipsec_program="/usr/local/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf" # allows setting up spd policies on boot
racoon_enable="yes"

Run:

sysctl net.inet.ipsec.filtertunnel=1
sysctl net.inet6.ipsec6.filtertunnel=1

Add to /etc/sysctl.conf to persist:

# IPSec filtering
net.inet.ipsec.filtertunnel=1
net.inet6.ipsec6.filtertunnel=1

Setup Google Authenticator on FreeBSD

Sun, 12 Jan 2014 00:00:00 +0100

Run as root:

cd /usr/ports/security/pam_google_authenticator
make install
mkdir /var/lib/google-authenticator

Edit /etc/pam.d/sshd:

auth      required    pam_google_authenticator.so nullok noskewadj

Edit /etc/pam.d/system:

auth      required    pam_google_authenticator.so nullok noskewadj

Leave out nullok if you do not want to allow users without having google-authenticator configured to be able to log in.
Be sure your root account has google-authenticator setup if you remove nullok and added it to /etc/pam.d/system.

Run google-authenticator with every user you want to be able to use it.

Securing FreeBSD. A living Post.

Sat, 11 Jan 2014 00:00:00 +0100

In this post I’m collecting snippets that make FreeBSD more secure.
I’ll be making updates to this post on an ongoing basis.

Do not allow unprivileged users to use the ptrace system call

To disable ptrace for unprivileged users, run as root:

sysctl security.bsd.unprivileged_proc_debug=0
echo 'security.bsd.unprivileged_proc_debug=0' >> /etc/sysctl.conf

More information: FreeBSD Security Advisory FreeBSD-SA-13:06.mmap [REVISED]

ZFS Full Disk Encryption with FreeBSD 10 - Part 2

Tue, 07 Jan 2014 00:00:00 +0100

Part 1

Before continuing, be sure to read part 1 of this blogpost.

What you will need

1 at least 1GB USB stick for the FreeBSD installer image
1 or more xGB USB sticks for the boot files and encryption keys

You should create multiple copies of the USB stick that holds the boot files and encryption keys. If you lose the stick or the data gets corrupted and you don’t have another copy, all your data stored on the encrypted disks is lost.

Booting the FreeBSD Installer

I’m using a USB stick with the FreeBSD 10 memstick image to boot into the FreeBSD installer. See here for a Mac OS X guide on how to get the memstick image onto a USB stick.

Now after your system finishes booting from the USB stick, it should present you with a blue, text-based installer giving you three options:

Install
Shell
Live CD

We will start by dropping into the shell and run su - to get a root shell.

SSHd

I will assume that your server is connected to your LAN during the installation. That way we can start an SSH daemon from the installer image and use our Mac or PC to enter the setup commands or copy files to the server.

So, on the shell on your server, run

ifconfig
bge0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=c019b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTSO,LINKSTATE>
	ether XX:XX:XX:XX:XX:XX
	nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
	media: Ethernet autoselect (1000baseT <full-duplex>)
	status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
	inet6 ::1 prefixlen 128 
	inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 
	inet 127.0.0.1 netmask 0xff000000 
	nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

to identify your network interface name. In my case it’s bge0.

And then:

dhclient <your-network-interface-name>
DHCPDISCOVER on bge0 to 255.255.255.255 port 67 interval 8
DHCPOFFER from 192.168.1.1
DHCPREQUEST on bge0 to 255.255.255.255 port 67
DHCPACK from 192.168.1.1
bound to 192.168.1.45 -- renewal in 21600 seconds.

to get an IPv4 address, in my case 192.168.1.45.

If your LAN does not offer you an IP address via DHCP, run man ifconfig and read up on how to configure a network card manually.

Let’s say your server is now connected to your LAN and has an IPv4 address. We can now start an SSH daemon by running:

mkdir /tmp/etc
mount_unionfs /tmp/etc /etc
echo "PermitRootLogin yes" >> /etc/ssh/sshd_config
passwd root
service sshd onestart

The root password you are asked to enter is just for the installer; it’s not the root password you will use later for your installation.

Now to login to the installer image by running ssh root@<ip-address-of-your-server> on your Mac or PC.

This guide should also work if you enter all the commands on the command line yourself, but doing it over SSH is more convenient.

Identifying your disks

Now let’s see which storage devices are connected to your server:

camcontrol devlist
<VB0250EAVER HPG9>                 at scbus0 target 0 lun 0 (pass0,ada0)
<VB0250EAVER HPG9>                 at scbus1 target 0 lun 0 (pass1,ada1)
<ST4000VN000-1H4168 SC43>          at scbus2 target 0 lun 0 (pass2,ada2)
<ST4000VN000-1H4168 SC43>          at scbus3 target 0 lun 0 (pass3,ada3)
<Sony USB Stick>                   at scbus6 target 0 lun 0 (pass4,da0)

In my case I have four hard disks and one USB stick (da0) We’ll create two zpools, one for the OS installation and for data. In my case I’ll use the disks ada0 and ada1 for the OS and ada2 and ada3 for my data.

The device names are probably different on your system. Please consult FreeBSD Disk device names to find out how FreeBSD names attached storage devices.

Randomizing

We will start by writing random data to the two operating system disks.

dd if=/dev/random of=/dev/ada0 bs=1m &
dd if=/dev/random of=/dev/ada1 bs=1m

This will take a very long time, depending on how big your disks are.

Partitioning

Now let’s start partitioning the disks. This is what the layout will look like in the end:

| Hard Disk Device | Partition 1               | Partition 2                        |
-------------------------------------------------------------------------------------
| ada0             | ada0p1 freebsd-swap       | ada0p2 freebsd-zfs OS installation |
| ada1             | ada1p1 freebsd-swap       | ada1p2 freebsd-zfs OS installation |
-------------------------------------------------------------------------------------

As I said, we are going to store the bootcode, kernel and keyfiles on a USB stick, so there is no need for a boot partition.

You might also notice that we’ll create separate swap partitions and won’t use a ZVOL for swap. Here is why.

The next steps will destroy any data on your drives:

To better understand the following commands it would be a good idea to read the manpage of gpart: man gpart.

Clean the drives of existing partition tables:

gpart destroy -F ada0
gpart destroy -F ada1

If you get a message like gpart: arg0 'ada2': Invalid argument, that’s fine and you can ignore it. It just means that there was no partition table on the disk anyway.

Create a GPT partition table on each disk:

gpart create -s gpt ada0
gpart create -s gpt ada1

Nowadays, disks (especially very large ones) use a sector format called “Advanced Format”. Long story short, even if you don’t have Advanced Format disks, we are going to align the partitions with 4K sectors. This blog post explains it quite well in a ZFS/FreeBSD context.

Next we are going to create the swap partition. You will have to choose how big your swap partition is going to be. I’ll create a swap partition of the same size as the memory I’m planning on having in the server, so I’ll choose 16GB. You might have different needs. https://wiki.freebsd.org/SystemTuning#Swap suggests the following:

Size swap space to approximately twice the size of main memory on systems with less than 4GB RAM and the size of main memory for systems with more than 4GB. If in doubt, allocate more swap; allocating insufficient swap is far worse than allocating too much. If the system has multiple disks, reduce swap I/O contention by spreading swap across the disks, ideally in equally sized partitions.

We are using labels so we can more easily replace hardware later.

gpart add -l swap0 -t freebsd-swap -a 1m -s 16G ada0 # start at 4096 * 256 byte
gpart add -l swap1 -t freebsd-swap -a 1m -s 16G ada1 # start at 4096 * 256 byte

Now for the OS partition. Because I still have a few spare 160GB drives, I’m only going to use 140GB for the OS partition, so that if one of the current disks fails, I can easily replace it with one of my 160GB spares.

gpart add -l zroot0 -s 140G -t freebsd-zfs ada0 # only use 140GB
gpart add -l zroot1 -s 140G -t freebsd-zfs ada1 # only use 140GB

If you want to use all the remaining space on your disks (which is what I would normally do), run this instead:

gpart add -l zroot0 -t freebsd-zfs ada0 # use the whole remaining space
gpart add -l zroot1 -t freebsd-zfs ada1 # use the whole remaining space

What have we done?

root@:~ # gpart show ada0
=>       34  390721901  ada0  GPT  (186G)
         34       2014        - free -  (1.0M)
       2048   33554432     1  freebsd-swap  (16G)
   33556480  293601280     2  freebsd-zfs  (140G)
  327157760   63564175        - free -  (30G)

root@:~ #  gpart show ada1
=>       34  488397101  ada1  GPT  (233G)
         34       2014        - free -  (1.0M)
       2048   33554432     1  freebsd-swap  (16G)
   33556480  454840655     2  freebsd-zfs  (217G)

We will come back to the two empty data disks later.

SWAP Raid 1

Since we have two OS disks that…

kldload geom_mirror
gmirror label -b load -F swap /dev/gpt/swap0 /dev/gpt/swap1

Encryption

We are going to use GELI for the encryption. Basically it will encrypt each sector transparently. ZFS itself doesn’t know it is being encrypted:

| ZFS                |
| GELI Encryption    | 
| Physical Hard Disk |

Preparation

Load the kernel modules that are needed for GEOM and ZFS:

kldload opensolaris
kldload zfs
kldload geom_eli

Swap

geli onetime -d -e AES-XTS -l 256 -s 4096 /dev/mirror/swap

Operating System Partitions

Insert the USB stick that you plan to use as a boot device. Mine is da1. You will usually see some debug output about the just-connected USB stick on the server shell (not via SSH). It should also show the device name.

But you can always check your devices again with:

camcontrol devlist
<VB0250EAVER HPG9>                 at scbus0 target 0 lun 0 (pass0,ada0)
<VB0250EAVER HPG9>                 at scbus1 target 0 lun 0 (pass1,ada1)
<ST4000VN000-1H4168 SC43>          at scbus2 target 0 lun 0 (pass2,ada2)
<ST4000VN000-1H4168 SC43>          at scbus3 target 0 lun 0 (pass3,ada3)
<Sony USB Stick>                   at scbus6 target 0 lun 0 (pass4,da0)
<Sony USB Stick>                   at scbus7 target 0 lun 0 (da1,pass5)

Create the boot partition and install bootcode:

gpart destroy -F da1
gpart create -s gpt da1

gpart add -l gptboot0 -s 512k -t freebsd-boot da1

gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1

Let’s create the ZFS partition and boot pool:

gpart add -l boot0 -t freebsd-zfs da1

mkdir -p /tmp/mnt/bootpool

zpool create -m /tmp/mnt/bootpool bootpool /dev/gpt/boot0

mkdir -p /tmp/mnt/bootpool/boot/zfs

mount_nullfs /tmp/mnt/bootpool/boot/zfs /boot/zfs

Create OS encryption key:

mkdir /tmp/mnt/bootpool/boot/keys
dd if=/dev/random of=/tmp/mnt/bootpool/boot/keys/zroot_encryption.key bs=64 count=1

Encrypt OS disks:

Choosing your password how long

mkdir /tmp/mnt/bootpool/boot/metadata_backup

geli init -b -s 4096 -e AES-XTS -l 256 -K /tmp/mnt/bootpool/boot/keys/zroot_encryption.key -B /tmp/mnt/bootpool/boot/metadata_backup/ada0p2.eli /dev/ada0p2
geli init -b -s 4096 -e AES-XTS -l 256 -K /tmp/mnt/bootpool/boot/keys/zroot_encryption.key -B /tmp/mnt/bootpool/boot/metadata_backup/ada1p2.eli /dev/ada1p2

geli attach -k /tmp/mnt/bootpool/boot/keys/zroot_encryption.key /dev/ada0p2
geli attach -k /tmp/mnt/bootpool/boot/keys/zroot_encryption.key /dev/ada1p2

ZFS zroot pool

mkdir -p /tmp/mnt/zroot

zpool create -m none zroot mirror /dev/ada0p2.eli /dev/ada1p2.eli

zfs set checksum=on zroot
zfs set atime=off zroot
zfs create zroot/ROOT
zfs create -o mountpoint=/tmp/mnt/zroot zroot/ROOT/default

because the eli devices have a sector size of 4096, zpool create automatically uses ashift=12

check it with zdb

Remount boot pool:

umount /boot/zfs
umount /tmp/mnt/bootpool

mkdir /tmp/mnt/zroot/bootpool
zfs set mountpoint=/tmp/mnt/zroot/bootpool bootpool
zfs mount bootpool

mount_nullfs /tmp/mnt/zroot/bootpool/boot/zfs /boot/zfs

Mounts should look like:

root@:~ # mount
/dev/iso9660/FREEBSD_INSTALL on / (cd9660, local, read-only)
devfs on /dev (devfs, local, multilabel)
/dev/md0 on /var (ufs, local)
/dev/md1 on /tmp (ufs, local)
<above>:/tmp/etc on /etc (unionfs, local)
zroot/ROOT/default on /tmp/mnt/zroot (zfs, local, nfsv4acls)
bootpool on /tmp/mnt/zroot/bootpool (zfs, local, nfsv4acls)
/tmp/mnt/zroot/bootpool/boot/zfs on /boot/zfs (nullfs, local)

ZFS zroot filesystems

zfs create -o mountpoint=/tmp/mnt/zroot/tmp -o compression=lz4 -o exec=on -o setuid=off zroot/tmp
chmod 1777 /tmp/mnt/zroot/tmp

zfs create -o mountpoint=/tmp/mnt/zroot/usr -o canmount=off zroot/usr

zfs create zroot/usr/home
cd /tmp/mnt/zroot; ln -s /usr/home home

zfs create -o compression=lz4 -o setuid=off zroot/usr/ports
zfs create -o compression=lz4 -o exec=off -o setuid=off zroot/usr/src

zfs create -o mountpoint=/tmp/mnt/zroot/var zroot/var
zfs create -o compression=lz4 -o exec=off -o setuid=off zroot/var/crash
zfs create -o compression=lz4 -o exec=off -o setuid=off zroot/var/log

zfs create -o compression=lz4 -o atime=on zroot/var/mail

zfs create -o compression=lz4 -o exec=on -o setuid=off zroot/var/tmp
chmod 1777 /tmp/mnt/zroot/var/tmp

Installing the base system

Available packages:

ls /usr/freebsd-dist/
MANIFEST    base.txz    doc.txz     games.txz   kernel.txz  lib32.txz   ports.txz   src.txz

cd /tmp/mnt/zroot

unxz -c /usr/freebsd-dist/base.txz | tar xpf -
unxz -c /usr/freebsd-dist/kernel.txz | tar xpf -
unxz -c /usr/freebsd-dist/src.txz | tar xpf -
unxz -c /usr/freebsd-dist/ports.txz | tar xpf -

Now let’s chroot into the new system:

chroot /tmp/mnt/zroot

Setup /boot:

cd /
rm -r boot/zfs
mv boot/* bootpool/boot/
rm -r boot
ln -sf bootpool/boot

And an initial /boot/loader.conf that will load ZFS, encryption and settings for encrypted disks on boot:

echo 'zfs_load="YES"' > /boot/loader.conf
echo 'aesni_load="YES"' >> /boot/loader.conf
echo 'geom_mirror_load="YES"' >> /boot/loader.conf
echo 'geom_eli_load="YES"' >> /boot/loader.conf
echo 'geli_ada0p2_keyfile0_load="YES"' >> /boot/loader.conf
echo 'geli_ada0p2_keyfile0_type="ada0p2:geli_keyfile0"' >> /boot/loader.conf
echo 'geli_ada0p2_keyfile0_name="/boot/keys/zroot_encryption.key"' >> /boot/loader.conf
echo 'geli_ada1p2_keyfile0_load="YES"' >> /boot/loader.conf
echo 'geli_ada1p2_keyfile0_type="ada1p2:geli_keyfile0"' >> /boot/loader.conf
echo 'geli_ada1p2_keyfile0_name="/boot/keys/zroot_encryption.key"' >> /boot/loader.conf
echo 'vfs.root.mountfrom="zfs:zroot/ROOT/default"' >> /boot/loader.conf
echo 'zpool_cache_load="YES"' >> /boot/loader.conf
echo 'zpool_cache_type="/boot/zfs/zpool.cache"' >> /boot/loader.conf
echo 'zpool_cache_name="/boot/zfs/zpool.cache"' >> /boot/loader.conf

Set root password:

passwd root

Set timezone:

tzsetup

Setup /etc/rc.conf

Create file and enable ZFS:

echo 'zfs_enable="YES"' > /etc/rc.conf

Set keymap:

kbdmap

Select your keymap and then write the output to /etc/rc.conf

echo 'keymap="german.iso.kbd"' >> /etc/rc.conf

Set hostname:

set HOSTNAME=<name-of-your-host>
echo hostname="$HOSTNAME" >> /etc/rc.conf
hostname -s "$HOSTNAME"

Setup services. This is how I did it; you can change the ‘YES’ to ‘NO’ if you don’t want a service to be running on boot:

echo 'sshd_enable="YES"' >> /etc/rc.conf
echo 'moused_enable="NO"' >> /etc/rc.conf
echo 'ntpd_enable="YES"' >> /etc/rc.conf
echo 'powerd_enable="YES"' >> /etc/rc.conf
echo 'dumpdev="NO"' >> /etc/rc.conf

Setup network:

Again I assume that you have DHCP for IPv4 and router advertisements for IPv6. Don’t forget to use the correct device name, in my case bge0:

echo 'ifconfig_bge0="DHCP"' >> /etc/rc.conf
echo 'ifconfig_bge0_ipv6="inet6 accept_rtadv"' >> /etc/rc.conf

Setup mail:

cd /etc/mail
make aliases

Setup /etc/fstab

printf "# Device\t\tMountpoint\tFStype\tOptions\t\tDump\tPass#\n" > /etc/fstab
printf "/dev/mirror/swap.eli\t\tnone\tswap\tsw\t\t0\t0\n" >> /etc/fstab

Exit chroot:

exit

Unmount filesystems:

cd /
umount /boot/zfs
zfs unmount -a

Setup ZFS mountpoints

zfs set mountpoint=legacy zroot/ROOT/default
zfs set mountpoint=/tmp zroot/tmp
zfs set mountpoint=/usr zroot/usr
zfs set mountpoint=/var zroot/var
zfs set mountpoint=/bootpool bootpool

Reboot into the new system

reboot

Creating a backup boot USB stick

gpart destroy -F da1
gpart create -s gpt da1

gpart add -l gptboot0 -s 512k -t freebsd-boot da1
gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da1

gpart add -l boot0 -t freebsd-zfs da1

mkdir /mnt/boot
cp -r /bootpool/boot/* /mnt/boot/

zpool export bootpool

mkdir /mnt/newbootpool
zpool create -m /mnt/newbootpool bootpool /dev/da1p2

cd /mnt/newbootpool
mv /mnt/boot .

cd
zfs unmount bootpool
zfs set mountpoint=/bootpool bootpool

SSH exchange identification: Connection closed by remote host

Tue, 07 Jan 2014 00:00:00 +0100

When trying to connect to a remote server, you may sometimes get:

SSH exchange identification: Connection closed by remote host

This might indicate an ongoing brute force attack against your server (although there are several other reasons for that error message).

If you have other means to get a shell on your server, you can check if a brute force attack is happening by tailing /var/log/auth.log

tail -f /var/log/auth.log
Jan  7 00:57:57 hostname sshd[10654]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:57:57 hostname sshd[10655]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:57:58 hostname sshd[10656]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:57:59 hostname sshd[10657]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:57:59 hostname sshd[10639]: Failed password for root from 59.63.167.174 port 53081 ssh2
Jan  7 00:58:00 hostname sshd[10658]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:00 hostname sshd[10659]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:01 hostname sshd[10662]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:01 hostname sshd[10663]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:01 hostname sshd[10639]: Failed password for root from 59.63.167.174 port 53081 ssh2
Jan  7 00:58:01 hostname sshd[10639]: Disconnecting: Too many authentication failures for root [preauth]
Jan  7 00:58:01 hostname sshd[10639]: PAM 5 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=59.63.167.174  user=root
Jan  7 00:58:01 hostname sshd[10639]: PAM service(sshd) ignoring max retries; 6 > 3
Jan  7 00:58:02 hostname sshd[10665]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:06 hostname sshd[10666]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:07 hostname sshd[10668]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:08 hostname sshd[10669]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:13 hostname sshd[10689]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:14 hostname sshd[10692]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:19 hostname sshd[10695]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:25 hostname sshd[10697]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:31 hostname sshd[10699]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:37 hostname sshd[10716]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:42 hostname sshd[10730]: refused connect from 59.63.167.174 (59.63.167.174)
Jan  7 00:58:48 hostname sshd[10732]: refused connect from 59.63.167.174 (59.63.167.174)

In my case the IP 59.63.167.174 tried to crack my root user’s password by brute force, which of course wouldn’t have worked anyway as you should never permit root login over SSH.

We have mostly Debian or Ubuntu servers in production, and we usually install the package denyhosts, which can stop this kind of attack by automatically adding the offender’s IP address to /etc/hosts.deny.

Somehow that was forgotten during setup . . .

A simple sudo apt-get install denyhosts stopped the attack, and I no longer get SSH exchange identification: Connection closed by remote host when trying to connect.

ZFS Full Disk Encryption with FreeBSD 10 - Part 1

Mon, 06 Jan 2014 00:00:00 +0100

From the day I started using my first laptop, I became an only one computer guy.
All data worth keeping was stored on that laptop (and the ones that followed).

I didn’t like the idea of spreading my data over multiple machines like a home computer, an office computer and of course the laptop.
Having your data on only one machine makes backups simple, you always have your data with you, and you never loose control over your data as long as you keep your laptop nearby.

Well, I did diverge a bit from that philosophy and started using Dropbox to share files with colleagues and friends.

There is of course one problem with using only a laptop to store your data: you are pretty limited in your storage size.

I currently have a Retina MacBook Pro with a 512GB SSD drive that I use for my private data (gigabytes of photos and music) and professional development work, and I also have multiple virtual machines for testing and developing our software with different operating systems. So I usually keep on that Macbook only data that I cannot easily reproduce, and happily delete everything else.

Home NAS

Anyhow, I need more storage space and decided to get myself a home NAS system. But that means that I will now have another system that I don’t always have with me, one that might get stolen or be accessed by someone else while I’m not around.

So I need a system that securely encrypts all data at rest, which I can trust to contain no backdoors, and for which security vulnerabilities are timely published and fixed.

Because of the recent NSA revelations and news like Backdoor found in Linksys, Netgear Routers and Lavabit Case Unsealed: FBI Demands Companies Secretly Turn Over Crypto Keys, I don’t trust commercial closed source NAS solutions and went the DIY open source route.

I’d normally only run Linux on my servers, but in this case I’m going to opt for FreeBSD for three reasons:

Being able to use ZFS as the storage system. While in the Linux world we have Btrfs, it’s not yet considered stable (a coworker of mine experienced data loss first hand). There is also ZFS on Linux, but I’m not sure how stable it is and ZFS on FreeBSD is part of the OS.
I like the FreeBSD philosophy of developing the whole base operating system in tandem with the kernel.
I have never used FreeBSD before (aside from OS X) and would like to take the opportunity to get more familiar with it.

Hardware

After doing some research I found the HP ProLiant MicroServer line of servers. They are well-built, really inexpensive little machines.

I opted for the slightly older HP ProLiant MicroServer G7 N54L with 2GB ECC RAM - upgradeable to 16GB. The MicroServer came with a Seagate Barracuda 7200.12 250GB drive and three additional drive slots.

While not having any hardware encryption accelerators (which might have their own problems) it’s a nice and very cheap machine.

I’m getting started with a four-disk setup, which I can later expand to a six-disk setup by installing:

a 5.25” Bay Extension Frame
a PCIe SATA card. Those two cards should fit and have the added benefit of two external USB3 ports.

The four-disk setup looks like this:

MicroServer Bay 1: Operating System - 3.5” 250GB 7200RPM HDD
MicroServer Bay 2: Operating System - 2.5” 200GB 7200RPM HDD
MicroServer Bay 3: Data - 3.5” 4TB NAS HDD
MicroServer Bay 4: Data - 3.5” 4TB NAS HDD

I already had the 2.5” 200GB drive lying around and wanted to reuse it, so I printed a custom 2.5” to 3.5” adapter on our Printrbot. Don’t bother buying a 2.5” to 3.5” mounting frame as it won’t position the 2.5” disk to fit the connector of the drive bay in the MicroServer.

For the 4TB disks, the Seagate ST4000VN000 and WD Red series both seem like good choices.

In case of running low on storage, I’d move the two smaller OS disks to the 5.25” bay and install an additional PCIe SATA card as well as two more 4TB drives.

While the MicroServer could on its own support six drives by using a hacked BIOS, I prefer not to go that way. I want to be able to use the latest original HP BIOS and not have any unexpected problems due to running unsupported code.

So the six-disk setup would look like this:

5.25” Bay Extension Slot A: Operating System - 3.5” 250GB 7200RPM HDD
5.25” Bay Extension Slot B: Operating System - 2.5” 200GB 7200RPM HDD
MicroServer Bay 1: Data - 3.5” 4TB NAS HDD
MicroServer Bay 2: Data - 3.5” 4TB NAS HDD
MicroServer Bay 3: Data - 3.5” 4TB NAS HDD
MicroServer Bay 4: Data - 3.5” 4TB NAS HDD

The first thing I’m probably gonna upgrade later is the RAM. Officially the MicroServer N54L only supports 8GB of ECC RAM, but others seem to have no problems with running 16GB ECC as well.

A short word about ECC RAM: while non-ECC RAM would be cheaper and is also supported, don’t use it if you are running ZFS or you might lose your data!

I also bought four different USB sticks from three different brands that will store the bootloader, kernel and keyfiles, but more about that later. The smallest sticks I could get were 8GB, but much smaller ones would have been OK too.

Setup

It’s All About the Software, Baby!

Let’s finally talk about the setup, but first I’d like to note the blog posts that I based this guide on:

I’m probably going to mention the HP ProLiant MicroServer a few times, and some small details might be specific to my setup, but in general this guide should work on most machines.

I’m aware that there are solutions like FreeNAS or Nas4Free, but I prefer setting things up myself and having the latest FreeBSD version.

The Plan

The plan is to have two zpools:

zroot for the FreeBSD OS installation on the two smaller disks
zdata the pool I will use for storing my data (the whole reason I’m doing this setup)

Both zroot and zdata will be encrypted using 256-bit AES-XTS with GELI.
There will be no unencrypted data anywhere in the server, but we will create an unencrypted USB stick that contains /boot and the keyfiles that will be part of the passphrase to unlock the encrypted partitions.

The idea is that we create a two-factor-authentication: something you know and something you have.

If you want to boot the server and decrypt the disk contents, you have know your passphrase, as well as have the USB stick.

Without the USB stick or the passphrase, the disks cannot be decrypted. Because of that we will later create multiple backups of the USB stick, so if one gets broken, we have a backup.

Of course you now have the problem of securely storing the USB sticks. But even if an attacker steals the USB stick from you, or you forget to remove it after booting, the server is still protected by the passphrase.

The alternative would be to create a bootable partition on the OS disks and only protect the server with a passphrase. In that case you can just use the standard FreeBSD 10 installer and the automatic ZFS partitioning guide.

So what will the disk layout look like?

I’ll use the two smaller drives in a mirrored configuration for zroot and the two 4TB drives, also in a mirrored configuration, for zdata.
Here is a very good writeup on why it might be a better idea to use zmirror than zraid.

To find out more about the FreeBSD boot process on ZFS, have a look at:

How FreeBSD Boots on ZFS

Part 2

You will be able to find the actual install process in part two of this blog post.

How FreeBSD Boots on ZFS

Sun, 05 Jan 2014 00:00:00 +0100

UEFI

Because FreeBSD UEFI support is not yet finished, the following will only describe how FreeBSD boots on a BIOS-based machine.
For more information on UEFI booting on FreeBSD look here, and for information on UEFI in general here.

BIOS-Based System

On a BIOS-based system, the BIOS tries to find the MBR in the first 512 bytes of the installed hard disks. On the first hard disk where it finds an MBR it will start to execute the MBR’s boot code. The BIOS usually identifies the MBR by a special boot signature at the end of the MBR. More about that on Wikipedia.

The different MBRs available in FreeBSD are:

/boot/boot0: MBR with boot menu
/boot/mbr: MBR that just boots the active partition
/boot/pmbr: a protective MBR that’s part of a GPT-based disk layout. It’s the one we’re going to use here.

So what are the steps for getting the kernel into memory?
On a plain MBR x86 system, the boot chain ususually looks like this:

BIOS -> MBR (stage1) -> VBR (stage2) -> Boot Loader (stage3) on filesystem -> FreeBSD Kernel on filesystem

MBR = Master Boot Record = stage 1
VBR = Volume Boot Record = stage 2
The 3rd-stage boot loader is the one with the ASCII art splash screen.

And specifically in a non-ZFS FreeBSD system:

BIOS -> /boot/boot0 -> /boot/boot2 -> /boot/loader -> FreeBSD Kernel

The MBR - /boot/boot0 - is stored in the first block of the hard disk and the VBR - /boot/boot2 - in the first block of the partition.

|MBR     | Partition 1                       | Partition 2                       |
|MBR     | VBR | Filesystem of Partition 1   | VBR | Filesystem of Partition 2   |
|1 block | 1 b.|                             | 1 b.|                             |

I just want to note that when I say /boot/boot0, I’m referring to the copy of the MBR or VBR that you can find in /boot.
What I mean by this is that the file in /boot is not the actual MBR, but during installation of the OS, the installer copies the file /boot/boot0 into the first block of the hard disk.

GPT

Since an MBR-based partitioning scheme can only address drives smaller than 2TB a replacement was needed. That replacement is GPT (GUID Partition Table).

But BIOS-based systems still need an MBR. Thus, part of a GPT setup is the PMBR or protective MBR, which contains the boot code to load the 2nd boot loader stage, as well as a partition table that contains only one entry spanning the whole disk. That’s how the protective MBR got its name, because a non-GPT-aware OS will think there is a partition spanning the whole drive and I shouldn’t mess with it.

So for a GPT partition scheme the boot chain looks like:

BIOS -> /boot/pmbr -> /boot/gptboot -> /boot/loader -> FreeBSD Kernel

And the disk layout:

|PMBR    | GPT Header | Partition 1 of type freebsd-boot | Partition 2 | Partition n... |
|1 block | 33 blocks  | /boot/gptboot                    | filesystem  | filesystem     |

The BIOS loads the protective MBR, which looks at GPT header / partition table, finds the first FreeBSD boot partition, and starts executing the 2nd-stage boot loader (which is stored in the beginning of the partition): /boot/gptboot or with ZFS /boot/gptzfsboot.

The 2nd-stage boot loader tries to load the 3rd stage, which is /boot/loader in the case of FreeBSD.
I haven’t checked the other 2nd-stage boot loaders, but /boot/gptboot at least tries to load a kernel directly at /boot/kernel/kernel if it cannot find the 3rd-stage boot loader.

ZFS

With a ZFS-based system the 3rd stage would be /boot/zfsloader and the chain looks like:

BIOS -> /boot/pmbr -> /boot/gptzfsboot -> /boot/zfsloader -> FreeBSD Kernel

Both /boot/gptzfsboot and /boot/zfsloader are already able to read ZFS partitions and locate files necessary for booting.

After installing the boot stages to disk the disk would look like:

|MBR     | GPT Header | Partition 1                               | Partition 2                  |
|PMBR    | GPT Header | /boot/gptzfsboot (freebsd-boot partition) | freebsd-zfs containing /boot |
|1 block | 33 blocks  | usually not very big, e.g., 512k          | probably the zroot volume    |

1 block = 512 bytes

/boot/gptzfsboot starts at block 0 of partition 1

In a real setup you would probably have a freebsd-swap partition before or after the freebsd-zfs partition.

Some more information on the FreeBSD boot process on x86.

FreeBSD 10: does SWAP work on a ZVOL?

Sun, 05 Jan 2014 00:00:00 +0100

TL;DR: No, keep them on separate swap partitions.

–

I’m working on a secure ZFS installation for my home NAS and plan to use ZFS as the filesystem. One goal is to have everything on disk encrypted.

While the new FreeBSD 10 installer can automatically partition your hard disk with an encrypted ZFS setup, the swap partition is not encrypted.

I also plan to mirror the swap space, so that if one disk goes down in my RAID 1 (or zmirror) setup, the system will keep running. If you placed a swap partition on each disk in a two-disk setup and they were not mirrored, the system would crash if one disk became unresponsive.

So my first idea was just to store the swap space in the ZFS pool instead of creating a separate swap partition that would need to be mirrored and encrypted.

Now, there are two options to store swap space on a ZFS pool:

Use a file as swap space that is stored on a ZFS filesystem
Store the swap space in a ZVOL

The first option is a no-go, because in case of low memory, ZFS needs memory to manage the disk writes to the swap file, but as there is no memory available it needs to write to the swap file, but ZFS needs memory to manage the disk writes to the swap file . . .

The second option the internetz suggests is to create a ZVOL and use that as swap space. That seems to work on first sight, and even Sun/Oracle suggested it in a blog post.

Also, the FreeBSD Wiki has something to say on how to create a ZVOL usable for swap space:

zfs create -V 2G -o org.freebsd:swap=on -o checksum=off -o compression=off -o dedup=off -o sync=disabled -o primarycache=none zroot/swap

But they added a note:

If there is no real memory available, the system might become unresponsive.

Because storing the swap space in a ZVOL would be much more convenient (at least if you don’t need kernel crash dumps, which wouldn’t work this way), I wanted to try for myself.

I wrote a little C program that just allocates memory and then waits for 10 minutes so that the memory is not immediately released:

#include <stdio.h>
#include <stdlib.h>
#include <time.h>

void alloc_one_meg() {
    int number_of_bytes_of_int = (int)sizeof(int);
    int number_of_ints_for_one_megabyte = 1024*1024/number_of_bytes_of_int;
    int *megabyte = malloc(sizeof(int) * number_of_ints_for_one_megabyte);

    for (int i=0; i < number_of_ints_for_one_megabyte; i++) {
        megabyte[i] = rand();
    }
}

void waitFor (unsigned int secs) {
    printf("waiting for %d seconds\n", secs);

    int retTime = time(0) + secs;
    while (time(0) < retTime);
}

int main ( int argc, char *argv[] )
{
    if ( argc != 2 ) {
        printf( "usage: %s <megabytes>\n", argv[0] );

    } else  {

        int number_of_megabytes;
        sscanf (argv[1],"%d",&number_of_megabytes);

        for (int i=0; i < number_of_megabytes; i++) {
            alloc_one_meg();
        }

        printf("allocated %d MB\n", number_of_megabytes);

        waitFor(600);
    }
}

Download link: memory.c

You can compile and run the program on a vanilla FreeBSD installation by running:

# clang -o memory memory.c
# ./memory <number of megabytes>

My test system is a VMware virtual machine with 256MB RAM.

SWAP partition

Now let’s see how the system behaves if we run memory.c on an installation with a normal 2GB swap partition:

The system stays responsive and kills memory.c as soon as it runs out of swap space.

ZVOL

Now let’s try the same thing with the swap space on a ZVOL:

It still replies to ping requests, but it has stopped being responsive. You cannot kill memory.c or do anything else useful.

As you can see in the top output, which I had running on the second console, the system has 256MB RAM and 512MB swap space. So the 300MB shouldn’t even have used up the whole swap space.

And if you can trust the top output, it crashed with only about 60MB of swap space used.

Conclusion

Some people have suggested reserving memory via kernel parameters (in that case ZFSOnLinux), but I’m aiming for a stable, maintainable system and reserving memory might just delay the problem, if it helped at all.

So the way to go is to keep swap space off ZFS and use separate partitions - like the FreeBSD 10 ZFS installer already does.

Getting the FreeBSD 10 installer onto a USB stick under Mac OS X

Sat, 04 Jan 2014 00:00:00 +0100

The following commands will only work in Mac OS X. For other operating systems see the FreeBSD Handbook!

At the time of writing this post, FreeBSD 10 is in PRERELEASE mode and according to the Release Schedule is nearly finished. So let’s get the latest snapshot from:

ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/10.0/

After FreeBSD 10 has been released, just go to http://www.freebsd.org/where.html and download the latest RELEASE version.

I’m using the AMD64 memstick image as my server has a 64-bit CPU:

curl -O ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/10.0/FreeBSD-10.0-PRERELEASE-amd64-20131230-r260064-memstick.img

Now connect your USB stick to your Mac and find the device name with mount:

$ mount
/dev/disk1 on / (hfs, local, journaled)
devfs on /dev (devfs, local, nobrowse)
/dev/disk0s4 on /Volumes/BOOTCAMP (ntfs, local, read-only, noowners)
map -hosts on /net (autofs, nosuid, automounted, nobrowse)
map auto_home on /home (autofs, automounted, nobrowse)
/dev/disk2s1 on /Volumes/CORSAIR (msdos, local, nodev, nosuid, noowners)

Your output might look a bit different. My USB stick is fresh out of the box and is FAT32 (MS-DOS) formated and called CORSAIR.

If you’re not sure which line represents your USB stick:

Remove the USB stick from your Mac
Run mount
Insert your USB stick
Run mount again and find the volume that was added

The relevant line in my case is:

/dev/disk2s1 on /Volumes/CORSAIR (msdos, local, nodev, nosuid, noowners)

Note that the USB stick is represented by /dev/disk2.

It’s very important that you use the correct device shown on YOUR system. If you use the wrong disk, the following dd command WILL DESTROY your data!

Unmount the USB stick:

$ diskutil umount /dev/disk2s1
Volume CORSAIR on disk2s1 unmounted

Now write the FreeBSD installer image to the USB stick. This will take some time.

$ sudo dd if=FreeBSD-10.0-PRERELEASE-amd64-20131230-r260064-memstick.img of=/dev/disk2 bs=64k
$ sync

You can now safely remove the USB stick from your Mac and use it to boot into the FreeBSD installer.

Securing my WordPress Installation

Fri, 03 Jan 2014 00:00:00 +0100

I decided to reduce the number of possible attack vectors on my private server, and one of the first things that had to go was Apache2 and WordPress.

While WordPress is not a very maintenance-intensive piece of software, nothing improves security as much as moving to a static blog engine, Jekyll in my case, and deploying the generated static files on GitHub.

This is more or less a test post . . .

Hide PostgreSQL User in OS X Lion 10.7

Mon, 01 Aug 2011 02:20:16 +0200

After you install PostgreSQL 8.4 on Lion, a PostgreSQL user pops up in the login window. To hide system users (including the PostgreSQL user), type the following in your terminal:

sudo defaults write /Library/Preferences/com.apple.loginwindow Hide500Users -bool TRUE

Mac OS X 10.7 Lion TrueCrypt Howto

Tue, 07 Jun 2011 00:00:00 +0200

Just to save you some time: TrueCrypt 7.0a doesn’t work out of the box with Lion.