Thursday, June 5, 2014

Reset the Net

This won't come as a shock to anyone who knows me, but I'm in full support of Fight For The Future's Reset the Net campaign.

Surveillance is censorship. We need real surveillance reform, but since Congress has watered down the one bill that would actually take a first step almost beyond recognition, we can't depend on the government to reform itself. It's up to us now.
I'd like to announce a few things as part of Reset the Net.
One, (and this will, again, not come as a shock to some people), I am fully committing to deploying SSL, HTTP Strict Transport Security, and Perfect Forward Secrecy on strugee.net by the end of the year, and more likely, by the end of the summer. In addition, I'm committing to self-hosting decentralized alternatives to popular centralized services, at first for myself, but with the intention to hand out accounts to friends and family once it's stable.
Two, I adjusted my Tor relay's settings a while back, and I'd like to announce that it's officially gained the stable flag. Whoo!
That's all for now, but I'll be back later (probably) with more.

Thursday, April 10, 2014

My standard configuration

I use Arch GNU/Linux. I know how to use it very well, and I love it dearly.
One of the amazing things about Arch is that you get to build your system from the ground up (but without waiting for things to compile). Therefore, the system that I run is exactly what I want. It has no defaults; I've carefully chosen everything and I've put together configurations and scripts to work with the exact environment that I prefer. My system is truly mine, and you would only get that on a do-it-yourself distribution like Arch.
It's occured to me that I've never actually bothered to write down what, exactly, my preferred environment is. This would be useful for two reasons:

  • Other people may be interested
  • There are too many things that I configure, and I can't actually remember them when I go to install a new system. Therefore, there are a bunch of inconsistencies between my systems that really just shouldn't be there (and that annoy me when I run into them).

So, I have decided to publish a list of my standard setup. Here goes:
The standalone programs that I use regularly and always have installed are git, the Z Shell, Emacs (along with emacs-pkgbuild-mode), Firefox (along with all the GStreamer 0.10 plugins that it can use, and an English language pack), OpenSSH, sudo, pacmatic (with html2text), and Aura. I also always have Steam, Terminator, Pidgin, LibreOffice (Writer, Draw, Impress, the English language pack and the GNOME integration) and Nuvola Player. For that last one, I turn on the Dock Manager, Last.fm/Libre.fm, Lyrics Fetching, Media Keys, Notifications, Tray Icon, and Remote Player Interface (MPRIS) extensions. I also keep base-devel installed.
Utilities that I have installed but only use semi-regularly include strace, the Lynx web browser, rsync, cowsay, traceroute, nmap (with PyGTK for Zenmap), GNOME Tweak Tool, GNUCash, abs and pkgfile. I also install btrfs-progs (because I prefer btrfs for everything but /boot - that gets the ext4 treatment), and parted. I have Deja Dup, Bitcoin Core (aka bitcoin-qt), Brasero, devhelp (from GNOME), File Roller (from GNOME), Four-in-a-Row (also from GNOME), GNOME Software (GNOME's PackageKit frontend), GNOME Activity Journal (frontend to Zeitgeist), Anjuta (the GNOME development environment), Cheese, GNOME Chess, GNOME Clocks, GNOME Documents, GNOME Disk Utility, GNOME Mines, GNOME Music, GNOME Nettool, GNOME Nibbles, GNOME Robots, Quadrapassel (basically GNOME Tetris), GNOME Weather, and last but not least from the GNOME department, Seahorse. I also have the Android SDK installed from the AUR, and finally, while it's not strictly a utility, I should mention that I have pkgstats installed, to help out with Arch development.
I also have a small amount of extra documentation and other static files installed - namely, gnome-devel-docs, an offline copy of the Arch Wiki and the archlinux-wallpaper package.
If given the choice, I install using a GPT partition header. As stated above, I create a /boot partition formatted ext4, usually 256MB. I always create a swap partition - this is generally about 2GB, but it varies by installation. I create a /home partition, formatted btrfs inside a LUKS container, that's usually around 30GB - although I am looking to change this number, due to needing to store the Bitcoin block chain (and wanting room for some VMs). The rest of the hard drive, I generally fill with /. (I'm thinking about making / a fixed amount, and filling the rest of the drive with /home. But I'm not sure yet.) For the kernel, I use the stock Arch kernel but I keep the linux-lts package installed, just in case an upgrade to the regular kernel breaks. I have an extremely standard mkinitcpio.conf: the only differences to really note are that I have the encrypt hook added, and the keyboard hook earlier. For a bootloader, I use GRUB 2. I use the standard configuration except for the fact that I turn on the blue colors in /etc/default/grub.
All right, so we've covered filesystems. We've covered applications. Time to tackle the elephant in the room: desktop environment. I use the GNOME Shell as my desktop environment, so I have all of GNOME core installed (but I hand-pick extra applications, as you've probably guessed by the massive list of GNOME applications above). The extensions I have installed vary a bit, but I always have Dash to Dock (set to have autohide/intellihide on, set to switch workspaces when scrolling over any region of the dock, set to have an opacity of 50 and set to launch a new window when clicking on an icon), Caffeine, Drop Down Terminal (configured to use F1, so that I can use it with my Happy Hacking Keyboard), Messaging Menu, (with microblog statuses turned on), Media Player Indicator (integrated with the volume menu), Advanced Volume Mixer (set to "aggregated menu") and Topicons. I also always have Systemmonitor, Places Status Indicator, Removable Drive Menu, and User Themes - all of these come bundled with GNOME - turned on. Additionally, I have a couple extra backends installed: I have the libpurple backend for Telepathy installed, and I have GVFS backends for SMB, AFP, MTP and most importantly, a backend for GNOME Online Accounts. I also have a couple things installed to make stuff in GNOME Control Center work: Rygel, gnome-user-share, system-config-printer, vino, and (as I'll mention later) ntpd.
Because I use GNOME as my desktop environment, I always have the NetworkManager systemd service enabled - however, I make an important addition: I add nohook resolv.conf to /etc/dhcpcd.conf so that I can apply custom DNS settings without the DHCP daemon overwriting them. I then use this ability to set my /etc/resolv.conf to use DNS servers from the OpenNIC project. Actually, turns out you can do this simply by creating /etc/resolv.conf.head - this file will be prepended to the final /etc/resolv.conf, which has the advantage of automatically falling back on the DHCP-configured DNS if OpenNIC DNS fails for some reason. I also have ntpd, Avahi, and GDM enabled. I also have the server component of OpenSSH turned on - the only configuration change I make is to disable root access, as the default configuration is actually pretty secure. Finally, in the GNOME Control Center, I've turned on screen sharing (password-protected). I really should configure printing, but honestly, I can't be bothered.
As a final miscellaneous note, I configure DNSSEC validation everywhere I can. There are a couple key differences between some of my machines that I haven't covered here, but those are all due to machine-specific needs (e.g. one of my machines - my iMac - has a Bluetooth mouse, so I have the Bluez utilities installed). But those are boring to write about, so I'm not going to write about them.
I'm also planning to add ZeroTier One to my default configuration. However, I haven't gotten it to work quite right yet, so that'll have to wait until later.
That's all I can think of for now (except my shell, of course, but the configurations for that are already public). I'll be posting new blog posts when I make configuration changes from now on, so you'll hear about this again... sometime.

Monday, April 7, 2014

I [redacted] hate Apple

If you know me in real life, you know that it's no secret that I am not a fan of Apple's mobile products. They are disgusting:
  • They won't let you install apps not from the App Store without jailbreaking the device, and the criteria for getting apps into the App Store is not well-defined and rather arbitrary
  • They won't let you experiment with custom firmware
  • They push DRM
  • They're relatively tied to iTunes (which doesn't work on GNU/Linux)
  • You can't do anything real with them due to the highly restrictive security model (and the fact that guidelines for getting into the App Store are draconian)
  • They don't have an equivalent of Android Intents (so you can't e.g. change the default browser from Safari)
Those last two are obviously just my personal taste talking. However, the rest still stands. I hate Apple mobile products, and I would never buy one these days.
That all being said, I used to say that Apple computers aren't really all that bad. Yes, they do have problems:
  • OS X is the buggiest Unix on the block (see also)
  • Even though Darwin is open-source, the vast majority of Apple's desktop stack is closed-source (to name just one example: Quartz, the display server, is closed-source).
  • It's impossible to properly customize them (this is in large part due to the fact that the stack is closed, but Apple at its core doesn't really like users to customize all that much, IMHO).
 Those days are done. I can now say with certainty that I hate Apple computers, too. The first reason is obvious: the OS is annoying; I've just covered this above. However, it's not annoying enough that I can't use it on a daily basis (like Windows is). If I wasn't using GNU/Linux and didn't want to try a BSD, I'd be using OS X. It's has problems, but overall, it's a pretty dang good operating system. So let's talk about all the other reasons I now hate Apple computing products.

The wireless
I can't tell you why. I bet no one but Apple could tell you why. But it seems like every bloody Mac has a Broadcom chip. And, well, Broadcom is not known for excellent GNU/Linux support. It could be worse, but the Broadcom drivers are of the class of drivers that require firmware to operate. I dislike firmware in general, because it's non-free and I don't trust anything but free software, but to make matters even worse, Broadcom's licensing terms disallows redistributing their firmware. That means that on most Macs, in order to get on the internet using something other than OS X, you need to get on the internet. Think about that for a minute. Sucks, right?
I'm lucky enough to own a MacBook Pro that has a built-in ethernet port. People who have bought newer MacBook Pros don't have this luxury. In fact, probably the only way that I can think of to get an internet connection for these poor souls (besides screwing around with USB tethering or something) is to mount a live ISO, find the firmware directory (which may be quite hard depending on how the ISO is built, ahem Ubuntu), and put the Broadcom firmware in their. It's a nightmare.

The EFI firmware
Now, EFI in general is kind of weird. To name just one example, EFI drivers often remain loaded after the kernel is booted. And while Secure Boot is undoubtedly a good thing in the right circumstances, Restricted Boot is not. But overall, I don't have a problem with EFI or UEFI (EFI 2.0, the version that's widely deployed). I do have a problem with Apple's EFI, though. Here;'s the reason:
It is screwed up in every imaginable way.
Let's start with the basics: what it's supposed to be. The answer? No one knows. Apple's EFI is a weird mix between EFI and UEFI; it is both and neither at the same time. Well, that's a great start.
The second thing that annoys me about Apple EFI is the fact that it has no EFI shell. Now, obviously shells are kind of ugly, and Apple (being Apple) needs to make its firmware pretty. I have no problem with this, but it would have been nice if they could have included a shell behind a keyboard shortcut or something. But no, you won't find a EFI shell in Macs. Now that I think about it, it's probably for the better. The Frankenstein-esque mess that you'd find there, given the mix of EFI and UEFI, would probably be horrifying.
And that brings us neatly to the last part of the mess that is EFI on Macs: bless. How can I phrase this? What the hell, Apple. I can't even fathom what moon-man black magic bless does. Basically, you have to mount your EFI partition, then use bless to "bless" a file, a directory, a mountpoint (probably your EFI partition) or... something else. But I have no idea which one of these you do. I've done it a couple times, and it's awful. There's absolutely no documentation on exactly how the options affect the firmware. The manpage is lacking. It's dismal, because without properly "blessing" your chosen bootloader, the firmware won't boot it. It's so weird, I can't even fathom how it's supposed to work.


The graphics configuration
This one, I suppose, is not really Apple's fault. But it's still bloody annoying. Basically, Macs nowadays have two GPUs: one is an integrated Intel (which sucks, because it is Intel and it is integrated) and the other is a discrete AMD (which is relatively good, because it's AMD and it's descrete). The way that OS X handles this is to use the Intel GPU normally, but turn on the AMD GPU if you're using something like OpenGL or OpenCL. Clever, right?
Well, the GNU/Linux community hasn't quite caught up. Support for hybrid graphics, as this setup is called, is still early. And on an unrelated note, when I booted my brand-new Arch setup on my MacBook, the kernel hung due to KMS not working properly. And because I have to turn off KMS to boot, I can't get graphics. I've wasted about 8 hours trying to get this to work. It's a bloody nightmare.

The touchpad
This one I will again admit is not really Apple's fault. Only a little.
I'll keep this section short, but basically, the trackpads in Mac computers are (presumably) very complex in order to support the kinds of things that Apple does with them in OS X-land (think: natural scrolling, multitouch gestures, right-click can be either left-click or right-click, there isn't really a clear separation between left and right-click - it feels as though the trackpad is physically all one button - etc.). This unfortunately means that there really isn't a good trackpad driver for Macs. Back when I was using Debian, I came across a decent one, but even that one was sub-par - I never got right-click to work. It was a real problem, trust me.

AGH, I HATE APPLE! Anyway...

Friday, March 14, 2014

Plans for the new steevie (and a short personal update)

steevie
Replacement & encryption

So a week or so ago I ordered a super nice hard drive - a 120 GB Intel SSD (note: that links to the 80 GB version but I did get the 120 GB version). Unfortunately, there's been snail-mail problems and the drive hasn't come yet, but I'll make sure I get it eventually. I've been working on the new server in a VM, so when I do get the drive back, I can basically just image it with CloneZilla, expand a couple partitions (because I didn't want to take up a 120 GB slice of my hard drive space for the virtual hard drive image), and voila! New server.
A lot of things aren't worked out yet, due to time constraints and the fact that I could never really get VirtualBox's networking to work properly - I could never initiate a connection from the host to the guest, and screwing with the settings sometimes messed up the guest's outbound networking, too. However, the basic system is installed and functioning. The new steevie is architected from the ground up to resist the NSA. Every partition (except for /boot) is encrypted at the block level. My current plan is to have the partitions automatically unlocked with a GPG key in /boot, but I'm considering requiring a passphrase to unlock that key (yes, this does work, even with system encryption) - both of these are currently unimplemented; in the VM I just type the password manually. In addition, backups (I'm getting to my plan for these) will be encrypted with a separate GPG key that I'll keep in a secure physical storage location (password-protected, of course). Whenever possible, I will endevour to encrypt your data server-side at the application level (as opposed to the block level) - this is because even though block-level encryption is absolutely essential for resisting data compromise attacks while the system is off, it does nothing (repeat: nothing!) when the system is on.
It's worth taking a sidebar right now to explain: why encrypt at all if you're just going to unlock it automatically? The reason is that it makes the data easier to destroy. For example, if I have an unencrypted server system and I need to get rid of all the data on it to protect my users, I have to overwrite every sector of the drive with random data - that means that the amount of time it takes for data removal is directly proportional to the size of the drive. With an encrypted system, the amount of data that you need to overwrite is fixed and small. (And, as mentioned above, it adds the possibility of unlocking using a GPG key, which can then be password-protected and used over the network, getting rid of the automatic aspect.)
In addition, the contents of the /boot partition will be checksummed and compared with known good values every boot. I'm planning to deploy HTTPS (or an equivalent, like SSH tunneling) for all services on steevie, major or minor, and specifically for web-facing services, I will turn on Strict Transport Security, which means that once you've visited that service once, your browser will remember the certificate information and will be able to tell if you're getting MitM'd. This is because I'm a strong believer in the philosophy that anything that can be encrypted should be encrypted. It's not exactly incredibly expensive (you can get basic SSL/TLS certs for free, and it's not computationally expensive, either).

Filesystems
Stepping away from all the crypto, btrfs is used as the filesystem inside the LUKS containers instead of LVM (because compared to the management of btrfs, I hated LVM). (/boot is ext4.) /home and / are separate partitions, and there's something like 2 GB of swap (I forget). The drive is GPT. Honestly, there's not much else to say about filesystems.
Edit April 9: I forgot to mention that /usr is on a separate, unencrypted partition. This is because /usr is basically data managed by the package manager, so there's no need to encrypt it - and by not encrypting it, we can achieve a performance benefit.

Backups
And that brings us to our final topic - backups. I have a much better/more defined backup plan this time (i.e. it actually exists). Here it is:
First off, the internal drive will be regularly snapshotted with btrfs snapshots. What I'm thinking of doing is keeping yearly, permanent snapshots (i.e. they never go away, ever), and then keeping monthly snapshots that I rotate to make room.
Of course, that doesn't protect against the physical drive failing. For that, I'm going to do a monthly backups to an external drive with a nice tool (I'm currently looking at rdiff-backup as the probable solution). Said tool would perform incremental backups - ideally, it would produce diffs between files, but I'd also be okay with copying the entire file. (However, copying the entire directory structure even if it hasn't changed is unacceptable, and it will become clear why in a moment.)
As a second layer of protection, I plan to backup the entire directory hierarchy (no diffs) at specific intervals. Currently I'm thinking 6 months to a year, but I may change that to 1 month if I decide to take rotatable btrfs snapshots more often (like every day or something). I'm still deciding whether I will manually cp files for this, or use a tool (possibly the same tool used to make incremental backups).
As stated above, backups will be encrypted and stored in a secure, off-site location (i.e. my mom's house - the server is at my dad's). As stated earlier, the new steevie is designed from the ground up to be NSA-resistant, and because of that, I will never use something like Amazon S3 to store backups.

Miscellaneous
I'm thinking of getting a UPS for steevie, just in case. I'm still pondering this; they're very expensive.
This was basically an unwritten rule with the way I adminsitered the first steevie, but I'm making it written this time: with the possible exception of firmware, I will never put closed-source applications or services on steevie.
I'm also going to offer steevie's services to friends this time around. Maybe I can get them to ditch Facebook and Twitter if I provide a nice enough alternative.
If you have any questions, let me know in the comments or tweet me, either @strugee2 or @strugee_dot_net.

Small update on my life
I've been super busy with robotics and homework. At the beginning of the robotics season, I was like, "oh man, I gotta blog about the start of robotics" and then I pushed it off until the end of the season. It's now the off-season, and we're doing some work but not at as intense a pace as during the season, which is nice. We placed fifth at states.
Also, I don't go on IRC a lot anymore due to not having a bouncer. Instead, I go on the Stack Exchange network chat. I like to hang out in the Unix & Linux main room, The DMZ (main room for IT Security), and The Comms Room (main room for Server Fault). Even though they don't recieve a lot of noise, I'm also usually in the Bitcoin Lounge (main room for Bitcoin - duh), and finally, The Exit Node (main room for Tor).
Speaking of which, I've been running a Tor relay on Amazon EC2 for a while now, named strugees. I'm having some problems with it exhausting the bandwidth quota in like 2 days, then sitting there idling for 5 days, but I'm hoping to work it out eventually.
I've started using an online hosted instance of OwnCloud as a placeholder until I get OwnCloud set up on steevie. It's super nice - the main thing I use it for right now is the built-in cloud RSS reader. It's awesome.
Finally, I'm going to LinuxFest Northwest again this year, and I will actually be giving a talk on Arch GNU/Linux. I'm super, super pumped for that.

Have some extra money?
No, it's not for me. If you have some money that you want to donate, the Pitivi project, which is trying to make an entirely free and open source video editing suite, is running a fundraiser, and they deserve your support. So does the MediaGoblin fundraiser - MediaGoblin is trying to make an entirely federated replacement to media-sharing platforms like YouTube and Flikr. Again, go check them out, they're awesome.