Will it script?

I keep accumulating Raspberry Pi’s for various reasons, and it got to the point where keeping them updated was using up all my energy. I then started looking into having them update themselves. As usual, not all posts found on the internet are up to date (this blog is often guilty of that as well) so it took a bit of experimenting to get it working.

Prerequisites:

• Raspberry Pi, Model B
• Raspbian Stretch

What will be installed

• unattended-upgrades
• postfix

Preparations

Update and upgrade everything manually:

sudo apt-get update 
sudo apt-get dist-upgrade
sudo apt-get autoremove

Postfix

Postfix is a mail server which will be utilized to send update mails whenever an upgrade is installed. Even though we don’t want the work with managing upgrades, it is still nice to know whenever something happens.

Install postfix:

sudo apt-get install postfix

Configure postfix by editing the settings file. SUITABLE_HOST_URI_HERE can be anything, it will be used as part of the sender (setting it to a value that will help you identify the machine that was updated is recommended). In my case I am using G-Mail to deliver the notifications.

sudo nano /etc/postfix/main.cf

alias_maps = hash:/etc/aliases
myhostname = SUITABLE_HOST_URI_HERE

# MX record that corresponds to the domain of the the recipient address
relayhost = aspmx.l.google.com

inet_interfaces = loopback-only

inet_protocols = ipv4

Make sure this is commentented out, caused lots of problems:

#myorigin = /etc/mailname

Adding aliases to users

unattended-upgrades will be running as root, so we will need to add some aliases for the mail sending.

sudo nano /etc/aliases

Add this to the end of the file (if you want to use the user pi to send the emails):

root: pi
pi: user@gmail.com

Rebuild alias db and restart Postfix

sudo newaliases
sudo /etc/init.d/postfix start

unattended-upgrades

Now it’s time to install the package that will do the actual updating on the machine. Install unattended-upgrades:

sudo apt-get install unattended-upgrades 
sudo apt-get install apt-listchanges 
sudo apt-get install bsd-mailx

Configure it by editing the following file:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

Allow these sources:

"origin=Raspbian,codename=${distro_codename},label=Raspbian";
"origin=Raspberry Pi Foundation,codename=${distro_codename},label=Raspberry Pi Foundation";

It is also recommended to configure the blacklist to exclude certain packages that might need backups first, or have interactive upgrade procedures (like unifi):

Unattended-Upgrade::Package-Blacklist{
      "unifi";
};

Configure the mail user that will be used for the upgrade notifications:

Unattended-Upgrade::Mail "pi";

Enable notifications (also when upgrades are successful):

Unattended-Upgrade::MailOnlyOnError "false";

Some upgrades require reboots as well, so in order for it to be completely automatic (except for the blacklist) we need to allow the machine to restart as well:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-WithUsers "true";

Usually it isn’t a good idea to reboot when the machine may be in use, so wait until the following night:

Unattended-Upgrade::Automatic-Reboot-Time "02:00";

Now simply enable package lists to be fetched automatically, and enable unattended-upgrades:

sudo nano /etc/apt/apt.conf.d/20auto-upgrades

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Done. Hopefully the machine will take care of its own updates, and notifications will arrive.

“Keep it secret. Keep it safe”
- Gandalf the Grey

Passwords

We use passwords everywhere, so lets start with the basics: how passwords are broken, and what can we as users do to make ourselves less vulnerable?

Guessing

The most basic way of breaking a password is simply to guess it. As shown again and again, most people are clueless (or just plain stupid) when picking passwords. Studying some password leaks from prominent sites show some worrying similarities. This can be done automatically using dictionaries, preferably consisting of standard dictionaries mixed with commonly used passwords.

Obtaining and cracking password data

Having a better password is not necessarily a guarantee for safety, since attackers can go directly to the source and retrieve it from systems it is being used on, or by intercepting it when it is being used.

The former attack involves using a vulnerability in a system to get ahold of password files or data from a database that contains the user data. This data can (and should) be encrypted, but this is no guarantee that the data is safe.

The latter attack is based on variants of eavesdropping. Three variants come to mind directly:

1. Looking over ones shoulder.
2. Listening to network traffic on an unencrypted network
3. Phishing

Most people are aware of the first one, and are careful when using credit cards and ATMs to avoid letting other people see what their code is. What most people don’t realise is that eavesdropping on traffic on an unencrypted network is basically the same thing.

Using a open public network is equivalent to speaking not only your pin code out loud, but also your card number, name and security code. Everyone on that network can hear what you submit, and hence all that information is considered compromised.

Phishing is (again) a variant of basic eavesdropping. A fraudulent web page is setup to look like the site the attacker wants access to, and users are tricked into going to that site. The user then enters their credentials, which the attacker intercepts before redirecting the users to the real site where they are already logged in (or not, doesn’t really matter). The most common attack vector for this is likely spam mails (where the user is asked to confirm their data by entering it on the fraudulent web page), but other methods can be used to trick the user to the page.

Case studies

Let’s have a look at 2 prominent leaks. What we can learn from these is the following:

1. People cannot be trusted with choosing a secure password
2. Even being a large, known entity in the computer business doesn’t guarantee that you make the right decisions regarding how to protect named data.
3. Security implementations are made by people who aren’t necessarily to be trusted in choosing a secure encryption method.

LinkedIn

June 6, 2012 a user on a Russian forum has claimed to have downloaded 6.46 million user hashed passwords from LinkedIn. LinkedIn passwords where encrypted with the SHA-1 cryptographic hash function, but stored as unsalted hashes. What this means is that while they cannot be read in plaintext directly, it is easier to decipher them using pre-computed tables of passwords. What makes it even easier is that since the passwords are simple and common in their construction multiple accounts are opened at the same time. Once a single password is cracked, the attacker can match the encrypted string to multiple logins and know that all of these share the same password.

Adobe

October 4, 2013 Adobe stated that attackers illegally entered their network and obtained customer information. Further analysis of the dumped data later showed that around 150 million customers where affected.1 Adobe had chosen a different encryption strategy, which unfortunately has other vulnerabilities and flaws. Again, the top 10 consists of poorly chosen passwords.2

Improvement

The way to improve password security is simple.

1. Use better passwords. Randomly generated, at least 16 characters, both upper and lower case, numbers and symbols. This makes automated attacks and cracking much harder.
2. Never use a password on more than 1 site. All passwords must be unique, and never reused. This makes the collateral damage much smaller if a password is lost to an attacker.
3. Use a password manager to keep track of the passwords. Since no person will be able to remember these passwords, put effort into one really secure password for this password manager and look up passwords as needed.
4. Check if connections are secure before transmitting sensitive data. This includes checking that you are on the site you are supposed to be on and that the connection is encrypted.
5. Don’t use unencrypted networks. If you have to be on one (for instance while staying on a hotel), be prepared and use a VPN account to get an encrypted channel before transmitting sensitive data.

Conclusion

Having a long, complicated password is not enough, since we rely on other people to keep it safe in the systems where it is being used. If the data leaks on the side we are not responsible for, there is little we can do. The same is true for passwords that are intercepted when submitted.

Two-step verification

Having concluded that no matter a password is vulnerable no matter the complexity, another layer of security is needed. The emerging solution to this has different names depending on who is offering it, but what all solutions have in common is that authentication uses two steps. The first step involves providing a username and password. The second step is providing authentication via something the real user is in possession of. A common example of this is ATM card with a PIN code, where you need both possession of the card and the PIN to use it.

Using a time based security token

This variant uses a time based token, which is calculated based on the current time and an initial seed value. Each time the user is logging in an authentication app needs to be started, and this app will tell the user what the current code is for the chosen account. Using this code the user will be able to continue logging in. It’s worth noting that 3rd party clients for these services doesn’t always support this authentication mechanism. For these clients special passwords can be generated, but this essentially reduces security to standard password authentication again.

The following are popular sites using this mechanism.

• Google: About 2-Step Verification

• Facebook: Introducing Login Approvals. This is setup in the security settings. Also, see this page for instructions on how to use a standard authenticator for Facebook.

• Dropbox: How do I enable two-step verification on my account?

• Evernote: Two-Step Verification Available to All Users

• Github: Two-factor Authentication

A thorough list of sites supporting 2 factor authentication is available at Two factor auth.

Using app authentication

This variant keeps track of authentication requests, and the user will have to start the application and either grant or deny access to the login attempt.

• Twitter: Using login verification

Hardware connected tokens

Some sites use special hardware tokens that generates the secondary code. Other sites registers a phone number, and sends the code to the registered phone number when a login access attempt is made.

Protect your information hubs

It has been said multiple times that your email account is your most important account. Every time you setup a new account on a site, you enter this address as part of your identity. It is to this address all information from sites is sent, including password reminder/reset e-mail. If this account is compromised, all other accounts can be compromised simply by resetting/resending the passwords for those accounts by using the compromised email address. Simply put, it need to be the strongest link in your information chain.

Over time, other accounts have entered this identity carrying sphere, making users more vulnerable. One example is Facebook Login, which lets you register accounts and log in to sites using your logged in Facebook account. While it may be convenient for users, it also makes it necessary to have tighter control over those Facebook accounts (using good passwords and 2 step authentication). Much like e-mail accounts, once a frequently used Facebook account is compromised, the attacker has control over all connected accounts as well.

Avoid daisy-chaining

When setting up accounts it is common to also enter a backup address. For example, Google lets you setup a backup address to which password restore e-mails can be sent. Needless to say: for each such connection, the risk increases. All accounts that are in this chain need to have the same level of security, and the security of the information transfer between them must be guaranteed. Why this is important, and why daisy-chaining should be avoided need further explanation.

Everything leaks

The problem with security boils down to trust. Somewhere along the line, you are forced to trust other people with your data. And people, as cynical as it may sound, are not trustworthy. To quote Kevin Mitnick:

“Most people are sooo willing to be helpful.”3

People are raised to be friendly and helpful. It is the proper way. It builds a society we want to live in, a society where people hold the door open for you. A society where people help you when you need help. Where being service minded is strived for, and where the customer is always right.

While the customer is always right and your friendly neighbour is (hopefully) friendly, someone trying to take over your account is not. An attacker will use peoples willingness to help to their own advantage. Another example from Kevin Mitnick:

“What’s your name, sir?” the lady on the other end asked. I told her, “It should be under ‘U.S. Government’ ”—hoping she would correct my error… hoping it was an error. And at the same time hoping she would be helpful enough to give the name on the account. She did. “Are you Mike Martinez?” she asked. What the hell?! “Yes, I’m Mike. By the way, what’s my account number again?” […] She wasn’t the least bit suspicious and just read off the account number for me. […] I called the cell phone store back. The same young lady answered. I hung up, waited a bit, and tried again. This time I got a guy. I gave him “my” name, phone number, and account number. “I lost my last three invoices,” I said, and asked him to fax them to me right away. “I accidentally erased my address book off my cell phone and I need my bills to reconstruct it,” I said. “Within minutes, he was faxing the invoices.”3

Social Engineering

What Mitnick effectively demonstrates is how to manipulate people into doing what you want. By using other peoples willingness to help, information about somebody can be extracted.

Gaining access to someones account is like laying a puzzle. Pieces are collected, put together and then used to gather more information. The more information that is available to the attacker, the better the puzzle can be put together. More pieces mean more leverage when convincing people to help.

It is therefor of the outmost importance to not leak information that will help an attacker. Problem is, we all leak information, constantly.

David Pogue

David Pogue, journalist for the New York Times had attackers gain access to his account simply by gathering enough information on him from blogs and social networks to be able to guess the answers to his security questions asked when restoring the password.

Mat Honan

Mat Honan, writer for Wired lost everything on his computer after attackers where able to remotely wipe his computer by gaining access to his iCloud account. This was simply a casualty of war. What the attackers wanted access to his Twitter account. How this was accomplished was simple in nature, yet hard to be protected against since the components needed can be accessable to most attackers.

Assuming password reminder emails for Twitter would be sent to his email, the first logical step was to gain access to that account. When using the password reminder function for Gmail Google display a masked version of the backup email configured for the requested account. For Mat, the address was m••••n@me.com; the masking was in this case irrelevant.

The next step was to gain access to the iCloud address. With access to that account the Gmail account could be reset, and with the Gmail account the Twitter account could be taken over. First the attacker looked up the whois information of his personal domain, which is a public record of the ownership of a domain. Then they used the following technique:

“First you call Amazon and tell them you are the account holder, and want to add a credit card number to the account. All you need is the name on the account, an associated e-mail address, and the billing address. Amazon then allows you to input a new credit card[…] Then you hang up. Next you call back, and tell Amazon that you’ve lost access to your account. Upon providing a name, billing address, and the new credit card number you gave the company on the prior call, Amazon will allow you to add a new e-mail address to the account. From here, you go to the Amazon website, and send a password reset to the new e-mail account. This allows you to see all the credit cards on file for the account — not the complete numbers, just the last four digits.”

The attacker now had enough information available to convince someone working with support at AppleCare to issue a temporary password to the iCloud account. It did this despite the caller’s inability to correctly answer security questions for the account. Using the new temporary account, the attacker now had access to everything.

Matthew Prince

The founder and CEO of Cloudflare, Matthew Prince, had his corporate account breached using a similar technique. Prince had, unlike Honan, set up 2 factor authentication for his account (which was hosted by Google). When requesting a new password for a Google account that has 2 factor authentication, a security token is sent as either via text message or by a voice call to a phone number connected to the account. By calling AT&T (the cell provider with whom the recovery number was registered) the attacker was able to convince the AT&T operator to add a forwarding number to the voicemail of the registered number using his social security number. The attacker could then request a new password for the Google account, have the security token forwarded to his voicemail and gain access. All it took was publicly available information and a overly helpful person working support that night.

Naoki Hiroshima

Naoki Hiroshima was extorted into giving his twitter handle @n to an attacker that had gained control of his domain, e-mail and Facebook account. The attacker gained access by contacting PayPal and convincing the person doing support into handing over credit card details. Then the attacker used the masked credit card information to gain access to his GoDaddy account and change the domain settings, among them the MX records (which specifies the mail server connected to the domain). The attacker was then, according to all registered information, the new owner of mr Hiroshima’s domain. This was then used as the bargaining chip by the attacker. Here is a summary by the attacker himself:

- I called paypal and used some very simple engineering tactics to obtain the last four of your card (avoid this by calling paypal and asking the agent to add a note to your account to not release any details via phone)

I called godaddy and told them I had lost the card but I remembered the last four, the agent then allowed me to try a range of numbers (00-09 in your case

Josh Bryant

Josh Bryant is the co-founder and CEO of Droplr. He almost lost access to iCloud and the Amazon S3 storage for Droplr due to a attack using customer support.

The attacker researched publicly available information on mr Bryant, and used this information to convince Amazon to reset the password over the iPhone. After that they used the information they could find in the account to convince Apple support to add a secondary email as a restore email for the iCloud account.

The attack was intercepted by mr Bryant, who happened to be online at the time, and who called support right away and got access back.

Single Point of Failure

“No matter how complex, no matter how unique, your passwords can no longer protect you.”
- Matt Honan

The point this article tries to drive home is that all systems, regardless of competence and architecture, can have vulnerabilities that make it possible to compromise. No matter how secure your setup is on paper, it is only as strong as the weakest link. It is therefor your responsibility as a user to make sure your accounts are as safe as possible.

Or, to quote Josh Bryant:

Some of the biggest companies in the world have security that is only as good as a minimum-wage phone support worker who has the power to reset your account.

Live and abide by the following rules of thumb, and you’ve come a bit on the way to making it harder for an attacker.

• Use good, long, random passwords
• Never reuse passwords
• Use 2-factor authentication
• Be wary what you share with others
• Don’t use any information that can be guessed or researched for password recovery
• Have a separate, anonymous email account for password registration only, and never tell anyone about it. The account name should have no connection to you either by username or account holder name.
• Set the TTL for your MX records to a really long value if you use a custom domain for your e-mail
• If you own your domain name, use a service that conceals the ownership in public records
• Avoid single sign-on solutions. Don’t have one account for everything Amazon, one iCloud account that is connected to the App Store, Facebook login etc.
• Use sites such as have i been pwned regularly to see if any of the sites you use have been compromised.
• Be paranoid and always consider the worst possible outcome.

1. Anatomy of a password disaster - Adobe’s giant-sized cryptographic blunder
2. Top 100 Adobe Passwords with Count
3. Excerpt From: Kevin Mitnick - Ghost in the Wires: My Adventures as the Worlds most wanted hacker

Important!

This post was written January 12, 2013. Most (if not all of it) is likely outdated and/or inaccurate. The post will remain on the site for historic purposes only. Take it for what it is.

Background

Everywhere you go nowadays you have access to open WiFi networks (hotels, bars, public hotspots etc). The problem with these is that the traffic isn’t encrypted. This means that if the server you’re connecting to isn’t running your traffic over SSH, it is open for everyone to listen to in plaintext. So, to solve this we’ll setup a VPN server on our Pi, and connect through that when on public networks.

Installation

First off, lets update our package lists and packages to stay up to date with the latest and greatest:

sudo apt-get update
sudo apt-get upgrade

Next, lets install the VPN server software.

sudo apt-get install openswan xl2tpd ppp lsof

Once the installation finishes, it’s time to configure the server.

IPSEC, Iptables and network settings

The first thing we are going to configure is IPSEC. Start by editing /etc/ipsec.conf:

sudo nano /etc/ipsec.conf

and change the following:

protostack=auto

to

protostack=netkey

At the end of the file , append the following:

conn L2TP-PSK
    authby=secret
    pfs=no
    rekey=no
    type=tunnel
    esp=aes128-sha1
    ike=aes128-sha-modp1024
    ikelifetime=8h
    keylife=1h
    left=192.168.1.212
    leftnexthop=%defaultroute
    leftprotoport=17/1701
    right=%any
    rightprotoport=17/%any
    rightsubnetwithin=0.0.0.0/0
    auto=add
    dpddelay=10
    dpdtimeout=20
    dpdaction=clear

The mapping over port 0 in the setting rightprotoport=17/%any is a workaround for OSX based clients (such as Macs and iOS devices). The IP in left=192.168.1.212 needs to be changed to the IP address of your server running the VPN software.

Once done, save and exit. Now we need to setup rules for the firewall and IP traversal. First, lets make the changes needed for the system to remember the changes on reboot.

sudo nano /etc/sysctl.conf

In this file, edit the following settings:

net.ipv4.ip_forward=1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0

Next up, lets define a firewall file which will apply the IPTables settings on bootup:

sudo nano /etc/firewall-rules.sh

Enter the following in the file:

#!/bin/sh
IPT="/sbin/iptables"

$IPT --table nat --append POSTROUTING --jump MASQUERADE

If you have any other rules you want to setup on boot, just add them as well. Save and exit. Make the file executable and owned by root:

chown root /etc/firewall-rules.sh
chmod 700 /etc/firewall-rules.sh

Now, let’s add it on network initialisation:

sudo nano /etc/network/interfaces

In this file, right after your default network interface add a initialisation of the script:

pre-up /etc/firewall-rules.sh

For reference, I use only the ethernet port, and this is what my config looks like:

iface eth0 inet dhcp
pre-up /etc/firewall-rules.sh

For now, lets apply the rules manually:

sudo iptables --table nat --append POSTROUTING --jump MASQUERADE

And the network settings needed:

for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done

For some reason I couldn’t get that for loop to work via sudo; if that’s the case, simply do

sudo su

and execute it as root.

Now, verify the settings with the following:

 ipsec verify

L2TP

Start configuring L2TP by editing the main L2TP configuration file:

sudo nano /etc/xl2tpd/xl2tpd.conf

Append the following at the end of the file.The local IP should be the IP of the server running the VPN software. The ip range should be a range of addresses that are distributed to the connecting clients, and shouldn’t be in the normal DCHP IP range. Other this noting is that we will be doing authentication via PPP/PAM, so all users must be real users on the server. This has the advantage of the passwords being saved in /etc/passwd, and encrypted. We will also reject mschap due to vulnerabilities in that protocol.

[global]
ipsec saref = yes

[lns default]
local ip = 192.168.1.212
ip range = 192.168.10.235-192.168.10.250
refuse chap = yes
refuse pap = yes
unix authentication = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Save and exit. Next up, the options file we just specified above.

sudo nano /etc/ppp/options.xl2tpd

Enter the following settings:

ipcp-accept-local
ipcp-accept-remote
ms-dns 192.168.1.212
noccp
auth
mtu 1200
mru 1000
crtscts
hide-password
name l2tpd
proxyarp
debug
lock
connect-delay 5000
login

The login statement on the last line is needed for the PAM authentication to work. The ms-dns setting should point to your primary name server. If you are uncertain which that is, look it up in resolve.conf

cat /etc/resolve.conf

What you are looking for is the first line starting with nameserver. Note the IP address. If you’ve previously setup your Raspberry Pi as an Ad blocking server, you’ll likely want to point to that machine as your name server. It is possible to add multiple servers as well, it you want to set up a chain of fallback servers.

Now, we’ll add the services to rc so they’ll start automatically on bootup:

sudo update-rc.d ipsec defaults
sudo update-rc.d xl2tpd defaults

Adding Users

Now it’s time to add the users you need for VPN:

sudo adduser vpnuser1
sudo adduser vpnuser2

Remember the password you set for the user, since that will be used to authenticate later on. Also, make it a VPN user only by denying it standard login on the machine.

sudo usermod -s /sbin/nologin vpnuser1
sudo usermod -s /sbin/nologin vpnuser2

Now we need to setup the IPSEC secret:

sudo nano /etc/ipsec.secrets

In this file, add the following:

%any %any: PSK "asupersecretverylongkey"

where the key (of course) is better chosen, preferably long and random. Next up, setting up the allowed users for PAP, and assigning static IP addresses for them.

sudo nano /etc/ppp/pap-secrets

Here, add the following for each user you have set up. In my case, I’ve set up 2 users, and as such I assign 2 IP addresses from the range we specified in /etc/xl2tpd/xl2tpd.conf. The first column name is the username, the second is the name of the service we specified in /etc/ppp/options.xl2tpd. Third column should be an empty string, since we’ll be using pam for authentication. Last column is the IP address that will be assigned to the connecting user.

vpnuser1    l2tpd    ""    192.168.10.235
vpnuser2    l2tpd    ""    192.168.10.240

Save and exit. Finally, restart all services.

sudo /etc/init.d/pppd-dns restart
sudo /etc/init.d/ipsec restart  
sudo /etc/init.d/xl2tpd restart

Port forwarding

Since we are going to use our VPN solution from outside of our home network, we need to open up the ports 500,4500 and 1701 in our router.

You should now be able to connect using your preferred device both from within the network and from the outside.

Troubleshooting

There is a risk that I’ve missed something when documenting this. I tried documenting everything along the way, but during my own troubleshooting I kept going back and changing settings. If for some reason it doesn’t work, please let me know. Better still, if it doesn’t work, and you are able to fix it, let me know what the problem was and how you fixed it.

If (for some reason) not everything is working as intended, the following files are a good source for troubleshooting:

/var/log/auth.log
/var/log/syslog

Goal

To set up an adblocking server which blocks ads for everyone on the network.

How does it work?

We’re going to set up a local DNS server, for which we will set up rules relating to ad connected queries. These requests will be directed to a local web server, which always returns a 1x1px transparent gif. Other requests will be looked up in real DNS servers and returned to the requester.

What will be installed

• Pixelserv
• DNSMasq

Pixelserv

First off, lets download and configure the web server. In a suitable directory (where you will want the server files to be), download the pixelserv script, change it to executable and edit the file:

wget proxytunnel.sourceforge.net/files/pixelserv.pl.txt
mv pixelserv.pl.txt pixelserv
chmod 755 pixelserv
nano pixelserv

In the file you will need to configure the IP and port you want the server to run on. Since we’ll be using it to redirect ad requests, I recommend you run it at port 80 if possible. The IP should be the IP address of the machine running the server. If uncertain, check it by running

ifconfig

and look for the section belonging to the ethernet interface:

eth0      Link encap:Ethernet  HWaddr b8:27:eb:f5:85:df  
          inet addr:192.168.1.212  Bcast:192.168.1.255  Mask:255.255.255.0

The inet addr is the IP address you’re looking for.

DNSMasq

Next off we’re going to install DNSMasq, a lightweight DHCP and caching DNS server. It will allow us to set up rules for specific hosts (announce local machines on the local network, and override global DNS announcements).

DNSMasq is available in the official repository, so install it from there:

sudo apt-get install dnsmasq

Once apt finishes, edit the DNSMasq configuration file:

sudo nano /etc/dnsmasq.conf

At the end of this file, append an external reference to an adblocking dns file:

conf-file=/etc/dnsmasq.adblock.conf

Save and exit. Edit the new file referenced at the end of the main configuration file:

sudo nano /etc/dnsmasq.adblock.conf

In this file add your chosen rules. The following is an excerpt from the file I’m using; each row states that for the given address (rotation.affiliator.com), the IP address stated is returned (192.168.1.212). The IP that is returned should be the IP for the machine that is running Pixelserv (which in this case happens to be the same machine we’re configuring):

address=/www.adtoma.basefarm.net/192.168.1.212
address=/rotation.affiliator.com/192.168.1.212
address=/adserver.adtech.de/192.168.1.212
address=/track.adform.net/192.168.1.212

Save and exit. Configure your Pi to use itself as the primary DNS server, and fallback on OpenDNS and Google public DNS:

sudo nano /etc/resolv.conf

nameserver 192.168.1.212
nameserver 208.67.220.222
nameserver 208.67.220.220
nameserver 8.8.8.8
nameserver 8.8.4.4

Save and exit, and restart dnsmasq:

sudo service dnsmasq restart

The last step is to configure your router to point to the DNSMasq server as the primary nameserver. Done.

The Raspberry Pi is a perfect target for setting up your own wireless backup solutions if you live in a Apple centric environment. This guide will be based on a Raspbian install.

Prerequisites:

• Raspberry Pi, Model B
• Raspbian Wheezy

What will be installed

• HFS utils
• Netatalk 3.0.1
• Avahi

Mount external HFS+ partitions

First of all we need to be able to read and write to HFS+ partitions. In order to do that, we need to install HFS packages, and to mount our partitions properly. Lets start by installing the needed packages:

sudo apt-get install hfsplus hfsutils hfsprogs

I personally partitioned and formatted the external drive with Disk Utility on my Macbook Pro and just hooked it up to one of the USB ports on the Pi afterwards, but feel free to prepare the disk any way you want. Once you’re done, connect the disk to your pi and check the name of your disk.

sudo blkid

This will output something like the following:

/dev/mmcblk0p1: SEC_TYPE="msdos" UUID="3312-932F" TYPE="vfat" 
/dev/mmcblk0p2: UUID="b7b5ddff-ddb4-48dd-84d2-dd47bf00564a" TYPE="ext4" 
/dev/sda1: LABEL="EFI" UUID="70D6-1701" TYPE="vfat" 
/dev/sda2: UUID="3d6b835f-2632-3319-b4bf-ff23f9dc1260" LABEL="CloudCity" TYPE="hfsplus" 
/dev/sda3: UUID="c10e0de5-f900-3ecb-8780-89b815e02450" LABEL="Bespin" TYPE="hfsplus" 

Note the last 2 lines of the output; these correspond to the partitions created on the external disk, and are what we’ll be configuring for automounting.

Create mount points for your partitions; I have 2 partitions, so I created 2 directories to mount the partitions to.

sudo mkdir -p /mnt/bespin
sudo mkdir -p /mnt/cloudcity

In order to get the disk to automount on bootup, edit fstab and insert entries for the new partitions there:

sudo nano /etc/fstab

Insert the following, using the information you looked up earlier:

UUID=3d6b835f-2632-3319-b4bf-ff23f9dc1260    /mnt/cloudcity     hfsplus    force,defaults    0 0
UUID=c10e0de5-f900-3ecb-8780-89b815e02450    /mnt/bespin        hfsplus    force,defaults    0 0

From now on you will be able to reboot without having to login and mount the partitions manually. For now, lets mount the configured partitions manually and verify the setup in fstab:

sudo mount /mnt/bespin
sudo mount /mnt/cloudcity

Avahi, DB and security packages

Avahi is a open source implementation of Apples ZeroConf specification, which is what we’ll be using to announce the availability of the AFP shares in the network. We’ll also be installing database utils and crypt packages for security.

sudo apt-get install avahi-daemon libavahi-client-dev libdb5.3-dev db-util db5.3-util libgcrypt11 libgcrypt11-dev

Netatalk

Netatalk is what handles the actual AFP shares in the network. Using version 3 greatly simplifies the setup compared to version 2, which most guides I’ve come across is based on. Netatalk is not available in apt (at the time of writing), so we’ll set it up manually instead. First, download the sources from sourceforge. Unpack them in a suitable directory

cd
mkdir tarballs
cd tarballs
wget http://prdownloads.sourceforge.net/netatalk/netatalk-3.0.1.tar.gz?download
mv netatalk-3.0.1.tar.gz\?download netatalk-3.0.1.tar.gz
tar -zxvf netatalk-3.0.1.tar.gz
cd netatalk-3.0.1
./configure --with-init-style=debian --with-zeroconf && make && sudo make install

This will take some time; excellent opportunity for a coffee break. Next up, configuring Netatalk. First we’ll create a user for the time machine share:

sudo adduser timeuser

Change the permissions for the Time Machine drive:

sudo chown -R timeuser:timeuser /mnt/cloudcity

Next, it’s time to edit the config file for netatalk:

sudo nano /usr/local/etc/afp.conf

Here we’ll set up our shares. The Global section contains settings that applies for the entire Netatalk server. Important here is to change the IP mask so it matches your network; I allow access for everyone on my subnet. The following section is the AFP share meant for Time Machine. Note that we’ll use the same user we created earlier with the share.

[Global]
hosts allow = 192.168.1.0/24
log file = /var/log/netatalk.log

[Time Machine]
path = /mnt/cloudcity  
valid users = timeuser
time machine = yes

Save and exit. Now, let’s restart the service:

sudo service netatalk restart

Now your Raspberry Pi should appear in Finder, and you should b able to connect to it with the credentials you set up earlier.

Appearance

By editing (or creating if it doesn’t exist) the avahi conf file for afpd, we can make the icon for the Raspberry Pi appear as if it was a Time Capsule as well.

sudo nano /etc/avahi/services/afpd.service

Edit the file as follows:

<?xml version="1.0" standalone='no'?><!--*-nxml-*-->

<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
  <service-group>
    <name replace-wildcards="yes">%h</name>
  <service>
    <type>_afpovertcp._tcp</type>
    <port>548</port>
  </service>
  <service>
    <type>_device-info._tcp</type>
    <port>0</port>
    <txt-record>model=TimeCapsule</txt-record>
  </service>
</service-group>

As seen in the txt-record, the computer will now appear as a Time Capsule. Now, just restart avahi:

sudo service avahi-daemon restart

And you should be good to go. Now all that is left is to edit the Time Machine preferences and add your newly created Time Machine share as a Time Machine drive and it will (hopefully) start backing up.

Sparrow is the best mail client for OSX, hands down. It gets a lot of details right. Facebook integration for avatars. Excellent threading for conversations. The way attachments are handled through cloud services is simply brilliant. ¹

So, obviously it is a big deal when Sparrow for iPhone hits the app store. Some of the features have made the transition from OSX, such as the Facebook integration. Some didn’t, such as the way OS X handles attachments. I’ve spent the last days on Sparrow for iPhone, and it is a great client. As expected, it’s miles ahead of Mail.app. But all is not perfect either.

The lack of push notifications is not a problem, but it is annoying. This really is a problem with how Apples App Store guidelines. Today there simply isn’t a way to let an app like Sparrow have client side push. The alternative is to give your credentials to a server run by the Sparrow team, which in turn logs in, checks your mail and notifies you. Problem is, by doing that you’ve handed over your credentials to the most sensitive service you use; the one where all your passwords can be requested to.

In my setup I work around the problem by leaving my home computer running at all times, and have it check my mail. If I get new mail, I forward the notification with Prowl, which then has a redirect set up to open the main view in Sparrow. Not perfect, but it works. If my home connection goes down, I stop getting notifications. That in the other hand IS a problem.

If Apple opens up the possibility of using background processes in a way similar to thise used by VOIP apps, Sparrow can use local push notifications. This would be a much better solution.

For now it remains a good e-mail app for those able to run a 2 component setup like myself. For the rest, the appeal is a bit more limited.

Our development team recently got inspired by this project, and decided to get our own Thunder Missile launcher to launch missiles on developers pushing non working code for review. This beauty now sits on a workstation waiting for someone to break the build. We currently use Hudson as our Continuos Integration server, which in turn triggers the build on Gerrit events. So, each time someone submits for review, they are a potential target.

The missile launcher itself is controllable through a web server on the machine it is connected to. It is possible to control its behavior, as well as have it fire upon people be simple passing commands to the web server (but don’t tell anyone). To keep everyone focused it randomly patrols the room as well (random movement pattern on random intervals).

Things like these are not just fun and gimmicky. It also tells you something about the workplace itself. Being able to work someplace where setting up a something like this without management having any objections is a privilege. It builds team spirit, and keeps motivation up.

Needless to say, everyone on the team loves it.

Speaking of the developer guidelines for Android: the inconsistent behavior of the back button is the single most common irritation I’ve read when it comes to Android. If developers adhere to the new guidelines for Navigation with Back and Up this should mostly not be a problem any longer. A bit puzzling though why the guidelines is consistent in all cases but one: System-to-app navigation. I quote:

If the your app was reached via the system mechanisms of notifications or home screen widgets, Up behaves as described for app-to-app navigation, above.

For the Back key, you should make navigation more predictably by inserting into the task’s back stack the complete upward navigation path to the app’s topmost screen. This way, a user who has forgotten how they entered your app can safely navigate to the app’s topmost screen before exiting it.

Can’t really see why you would want to ruin a consistent behavior like this with special cases. And how would a user be any less confused by ending up at the topmost screen of the app? Other than that, solid recommendations.

Scriptogram, a new site with an interesting concept. It connects with your Dropbox account and converts Markdown documents found in a specific folder into blog posts. A few details:

• Markdown documents found in /Apps/scriptogram/posts are synchronized and converted into blog posts.
• Only the scriptogram folder is accessible to scriptogr.am
• Custom domains can be used for your blog
• Custom CSS can be used to personalize the appearance.

I other words: you don’t get any fancy JavaScript or advanced CSS class structure. What you do get is a basic, fast loading, easy to use and easily setup blog.