Kirsle.net
The free SSL certificate authority Let's Encrypt went into public beta earlier this month, and I updated all of my sites to use SSL now. I still had several more months before kirsle.net's old certificate from Namecheap expired, but I switched to the Let's Encrypt certificate because I could include all my subdomains instead of only the www one.
Check out their website and get free SSL certificates for your sites, too. I'm just writing this blog with some personal tips for how I configured my nginx server and a Python script I wrote to automate the process of renewing my certificates every month (Let's Encrypt certs expire every 90 days).
Last weekend I was pleasantly surprised to discover that Time Warner Cable already supports IPv6 at my apartment.
They shipped me a newer cable modem/WiFi router combo device earlier this year as part of their plan to upgrade everyone's Internet speeds in Los Angeles. I didn't realize that this modem also supported IPv6, and it wasn't enabled by default.
Today I picked up a Macbook Air (13", early 2015 model) because I wanted a new laptop, as my old laptop (the Samsung Series 5) has a horrible battery life, where it barely lasts over an hour and gives up early (powering down at 40% and not coming back up until I plug it in). This is also my first Apple computer. I'm the furthest thing from an Apple fanboy, but the choices I was throwing around in my head were between an Apple computer and a Lenovo Thinkpad.
I was given a Thinkpad as my work laptop, and it's by far the most impressive PC laptop I've ever used; it can drive three displays and run lots of concurrent tasks and has an insane battery life. Every PC laptop I've owned in the past have sucked in comparison. I hear people compare Apple computers to Thinkpads, so that's why the choice came down to one of these, and I didn't want another Thinkpad sitting around the house. ;)
Months before getting a Macbook I was looking into what kind of effort it takes to install Linux on a Macbook. There's a lot of information out there, and most of it suggests that the best way to go is to install a boot manager like rEFIt (or rEFInd, since rEFIt isn't maintained anymore). I saw some pages about not using rEFIt and installing Grub directly, which were from a Debian and Arch Linux perspective, and it sounded really complicated.
It seems that nowadays, with a user friendly Linux distribution like Fedora, a lot of this works much more flawlessly than the dozens of tutorials online would suggest. I just made a Fedora LiveUSB in the usual way (as if installing on a normal PC), rebooted the Macbook while holding the Option key, so that I was able to select the USB to boot from.
When installing Fedora to disk, the process was very much the same as doing it on a normal PC. I let Fedora automatically create the partition layout, and it created partitions and mount points for /, /boot and /home like usual, but it also created a partition and mount point for /boot/efi (for installing itself as the default bootloader in the EFI firmware on the Macbook). After installation was completed, I rebooted and the grub boot screen comes up immediately, with options to boot into Fedora.
One weird thing is, the grub screen apparently sees something related to Mac OS X (there were two entries, like "Mac OS X 32-bit" and "Mac OS X 64-bit", but both options would give error messages when picked).
If I want to boot into OS X, I hold down the Option key on boot and pick the Macintosh HD from the EFI boot menu. Otherwise, if the Macbook boots normally it goes into the grub menu and then Fedora. So, the whole thing is very similar to a typical PC dual-boot setup (with Windows and Linux), just with one extra step to get into OS X.
Update: I'm keeping a wiki page with miscellaneous setup notes and tips here: Fedora on Macbook
First and foremost: this requires the victim to click not one, but two random links sent to them over Pidgin (or any other program that does URL auto-linking the way Pidgin does). So it's not exactly the most severe vulnerability, but I found it interesting nonetheless.
I jumped ship from GNOME 2 to XFCE when GNOME 3 was announced and have ranted about it endlessly, but then I decided to give GNOME 3.14 (Fedora 21) a try.
I still installed Fedora XFCE on all the PCs I care about, and decided my personal laptop was the perfect guinea pig for GNOME because I never do anything with that laptop and wouldn't mind re-formatting it again for XFCE if I turn out not to like Gnome.
After scouring the GNOME Shell extensions I installed a handful that made my desktop somewhat tolerable:
(Click for bigger screenshot)
And then I found way too many little papercuts, some worse than others. My brief list:
Settings weren't always respected very well, and some apps would need to be "coerced" into actually looking at their settings. For example, I configured the GNOME Terminal to use a transparent background. It worked when I first set it up, but then it would rarely work after that. If I opened a new terminal, the background would be solid black. Adjusting the transparency setting now had no effect. Sometimes, opening and closing a tab would get GNOME Terminal to actually read its settings and turn transparent. Most of the time though, it didn't, and nothing I could do would get the transparency to come back on. It all depended on the alignment of the stars and when GNOME Terminal damn well feels like it.
Also, I use a left handed mouse, and GNOME Shell completely got confused after a reboot. The task bar and window buttons (maximize, close, etc.) and other Shell components would be right handed, while the actual apps I use would be left handed. So, clicking the scrollbar and links in Firefox would be left-handed (right mouse button is your "left click"), and when I wanted to close out of Firefox, I'd instead get a context menu popup when clicking the "X" button. Ugh!
I wanted to write this blog post from within GNOME but it just wasn't possible. With different parts of my GUI using right-handed buttons and other parts using left-handed ones, I had context menus popping up when I didn't want them and none popping up when I did. After a while I thought to go into the Mouse settings and switch it back; this didn't help, instead, the parts that used to be right-handed switched to left-handed, and vice versa. It was impossible to use. I just had to painstakingly get a screenshot off the laptop and to my desktop and deal with it over there instead.
These things just lead me to believe the GNOME developers only develop for their particular workflows and don't bother testing any features that other mere mortals might like to use. All the GNOME developers are probably right-handed, and they have no idea about the left-handed bugs. All of the GNOME developers don't use transparency in their terminals, evidenced by the fact that the transparency option disappeared from GNOME 3.0 and only just recently has made a comeback (in GNOME 3.12/Fedora 20).
XFCE is going back on this laptop.
A while after the Heartbleed SSL vulnerability made headlines, Wired.com ran an article titled "It's Time to Encrypt the Entire Internet" urging everyone to deploy SSL/TLS encryption on their sites.
SSL certificates tend to be pretty expensive, though, which is one reason I hadn't looked into it that closely in the past. In a Reddit comment thread about that Wired article some people mentioned Namecheap as a good option for simple SSL certs. So, I got a simple domain-level certificate for $9 for Kirsle.net. :) So all kirsle.net URLs are now running over https! This blog post is about the experience of setting up SSL and wrestling with various applications in the process.
The simplest guide I found that I followed to make a certificate was Generate CSR - Apache OpenSSL. One command creates a passphrase-protected key file, the next one generates the signing request:
openssl genrsa –des3 –out kirsle.key 2048
openssl req -new -key kirsle.key -out kirsle.csr
You apparently need a 2048-bit RSA key these days before a Certificate Authority will consider your signing request. I pasted in my CSR file and filled out some forms, got an e-mail verification sent to the address on my WHOIS record for my domain, and before I knew it I was e-mailed a zip file containing my certificate and the Comodo CA certificates.
Various apps will need your Certificate Authority's chain to be in a single file. You can create this file by catting the certificates into one file in "reverse" order, with your site's certificate on top, and the root certificate on bottom. Comodo gave me these files (and this is also the order for the chain file):
www_kirsle_net.crtCOMODORSADomainValidationSecureServerCA.crtCOMODORSAAddTrustCA.crtAddTrustExternalCARoot.crtSo I generated the chain as follows:
cat www_kirsle_net.crt COMODORSADomainValidationSecureServerCA.crt \
COMODORSAAddTrustCA.crt AddTrustExternalCARoot.crt > cacert.pem
I'm running a Debian server, so I just symlinked the ssl.load and ssl.conf files from my /etc/apache2/mods-available into my mods-enabled, and then edited the ssl.conf. All I changed in it was to uncomment the SSLHonorCipherOrder on line.
I removed the sites-enabled/default-ssl and then edited my Kirsle.net config file to add a <VirtualHost *:443> version. I had to look at the default-ssl file to get an idea which options were needed (if I missed any, Apache would fail to start!)
Relevant SSL options for my VirtualHost:
# SSL
SSLEngine on
SSLCertificateChainFile /etc/ssl/crt/cacert.pem
SSLCertificateFile /etc/ssl/crt/www_kirsle_net.crt
SSLCertificateKeyFile /etc/ssl/crt/kirsle.key
SSLOptions +StdEnvVars
BrowserMatch "MSIE [2-6]" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
Note: if you leave out the chain file, web browsers will still behave fine (because they're smart enough to download the intermediary certificates themselves), but other things will break. For example, the Python requests module will throw an SSL exception if the server doesn't give it the intermediary certificates!
After making sure https://www.kirsle.net/ was working, I made an update to my Rophako CMS to support SSL sites better and then made the switch-over. Any requests going to my HTTP Kirsle.net are redirected to the SSL version and given a Strict Transport Security header.
As a fun side note, Apache supports Perfect Forward Secrecy by default (using the default SSLCipherSuite option of HIGH:MEDIUM:!aNULL:!MD5).
Starting or restarting Apache requires you to enter the SSL key's passphrase at the command line. For simple config updates, service apache2 graceful will reload them without needing a full restart, so you don't need to enter the passphrase then.
I use Dovecot for my IMAP mail server on Kirsle.net, and I wanted it to use my shiny new SSL certificate. Before this, I was using a self-signed certificate, and apparently Thunderbird doesn't even warn you if that self-signed certificate changes at any point. After the Heartbleed vulnerability was fixed, I re-generated new self-signed certs and was shocked that Thunderbird happily accepted the new certificate without even telling me. It would've been extremely easy to Man-in-the-Middle my e-mail server. (I had since then installed an extension in Thunderbird to police SSL certificates for me as a workaround).
So, configuration is pretty simple, just edit /etc/dovecot/conf.d/10-ssl.conf and enter in the new paths to your chain file and private key. Note that if you use just your domain's certificate, clients like Thunderbird that support SSL properly will complain about the certificate being insecure, and unlike web browsers, Thunderbird doesn't bother downloading the intermediary certificates itself.
One catch with Dovecot is that if your private key file is encrypted with a passphrase like mine is, doing service dovecot restart won't work. Dovecot will start in a way where it won't support TLS but will otherwise appear to function normally.
To start Dovecot with a passphrase, you need to run dovecot -p (as root) to start the service. It will prompt for your passphrase at the command line and then start up. The service can be stopped normally using service dovecot stop.
This one I'm a bit upset about. Postfix has absolutely NO support for using a passphrase protected TLS key file! Even their official documentation states that the key file must not be encrypted.
That is so full of wtf. Postfix is a widely deployed SMTP server for Linux, and it has to use insecure, unprotected TLS key files. So, I'm still using a self-signed certificate for Postfix (and my Thunderbird add-on will tell me if this certificate ever changes, so don't get any ideas!). I don't send outgoing mail very often, anyway, and if I care enough I'll PGP encrypt. But, I'll be looking into an alternative SMTP server sometime soon.
I ran into this problem a couple different times on different machines running Fedora over the span of about the last 6 months. I had to Google it both times to find a solution (which wasn't easy to find), so here's the solution that ended up working for me each time.
~/.config/google-musicmanager~/Music folder (if you already downloaded songs from Google, move them to some other place). You'll see why in step #8.
Also, if you can't get the Music Manager to start at all in the first place, try running it from a terminal window with the google-musicmanager command and see what it says. On Fedora, it told me "error while loading shared libraries: libQtWebKit.so.4", and I just had to yum install qtwebkit to fix it (the MusicManager RPM didn't correctly list this dependency). When you see this or similar errors in Fedora, you can use a command similar to yum provides '*/libQtWebKit.so.4' and see what packages provide the missing file, and know what to install from there.
I'm going to compare it to Raspbian, which is the usual OS that people install on their Raspberry Pi's.
As far as speed goes, Fedora 18 runs pretty well on this device. I haven't directly compared it side-by-side with Raspbian, but I haven't noticed any real annoying slow-downs at all. They've optimized Fedora 18 to run well and take full advantage of the floating point unit on the Pi, which previous versions of Fedora didn't do.
One huge plus with Fedora over Raspbian is that the NetworkManager applet comes installed and set up by default (as it does on all Fedora OS's). It was super easy to connect to my wifi network with it. Under Raspbian, there's only the wpa_gui, and it doesn't work very well for me and I have to click the "Connect" button a dozen times before it finally connects. The NetworkManager applet is a huge improvement.
The Pidora distro comes with the XFCE desktop environment, as opposed to Raspbian's LXDE desktop (on my Raspbian, I had gone ahead and installed XFCE anyway). On my setup, audio was working how I want it to out-of-the-box. I have my Pi connected to a DVI monitor, using an HDMI to DVI adapter. In Raspbian, I had to uninstall Pulse and hack ALSA up to make it send audio out the analog jack instead of HDMI, so that I could connect it to some proper speakers. In Pidora, Pulse wasn't even installed by default, and ALSA already knew to send the audio through the analog jack.
I also managed to get Minecraft: Pi Edition to run on Pidora. I just needed to install libpng12 and SDL, and fix the permissions on the vchiq device (using instructions I found on the Raspbian Quake3 page), and I was good to go.
The biggest downside to Pidora is that there is no RPMFusion for it. They rebuilt pretty much all of the standard Fedora packages for the ARMv6 architecture, but upstream Fedora doesn't include anything non-free, like MP3 support, and so Pidora doesn't have that available in their repos either. Raspbian is a better bet if you need MP3 and video codec support, unless you want to compile the software yourself.
I think I'll stick with Pidora though. It's a lot more familiar since I run Fedora on all my other computers, and pretty much everything about Fedora is exactly the same in Pidora. :)
I recently got a Samsung Series 5 Ultrabook which has a touchscreen on it. After having trouble getting Windows 8 how I want it on this laptop, I installed Fedora w/ XFCE across the entire disk. I got motivated to try again with Windows 8, though, because it's a shame having a touchscreen and no software that knows how to use it properly.
XFCE doesn't work well with a touchscreen. I can't move windows around on it by touching and dragging their title bars. I can't highlight text.. when I touch and drag over text, it selects it, but it immediately de-selects as soon as I let go. About the only thing I can do on XFCE is click on things, and scroll a window by touching and dragging the scroll bar.
Before dealing with repartitioning and getting Windows 8 back on there, I decided I'd yum groupinstall "GNOME Desktop" and see how well Gnome Shell works with this touchscreen.
The first thing I tested was dragging windows around. It works. I opened Firefox and dragged inside a web page, which highlighted text (don't remember if the text stayed highlighted though). Dragging the scrollbar worked.
I opened Nautilus and navigated to /usr/share by touching the icons. This folder had a scrollbar. I could drag the scrollbar just like in Firefox, but I could also scroll the window by touching anywhere else in the window and swiping, just like you'd expect on Android or iOS. It supported acceleration too, where you could swipe quickly and let go and the window would continue scrolling and eventually slow down.
Dragging windows around in the Activities view worked exactly how you'd expect, too.
Gnome Shell doesn't support multi-touch, though. But I think this is the fault of X11 in general not supporting it, so you can't blame them for that. If you try a multi-touch gesture, it just gets confused and tries to treat all your fingers as one and you get erratic mouse movements or something.
I still don't like Gnome, but I am impressed that this actually works, for all the propaganda you hear from the Gnome devs about making it a tablet interface. I was expecting it to be as painful to use as XFCE on a touch screen.
Now, to install Windows 8 and then put Fedora XFCE back on. ;)
I've used three computers that came with various kinds of AMD graphics cards, and all of them have given me nothing but problems in Linux. The first one was an ATI Radeon Xpress 200M, built into an old laptop I bought in 2007. This video card appears to have already been obsoleted by AMD at the time I bought the laptop, but that's another story.
The Xpress 200M card was problematic for both Linux and Windows. It only worked reasonably well with Windows XP; and it's entirely not supported by any means in Windows 7 or 8. In Linux, I can only use the open source radeon driver with it, but that doesn't give me any kind of hardware acceleration. If I install the fglrx driver (AMD's closed source proprietary one), it makes the system completely unstable, and random kernel panics and freezes become very common.
My second computer with an AMD video card was a Dell Studio XPS desktop. I don't remember the exact model number of this AMD card, but it was somewhere in the mid-range area. I installed the fglrx driver in Linux, and it worked reasonably well, except every once in a while my screen would completely go black, and then I could bring back parts of my display by "refreshing" them (i.e. moving my mouse around, dragging a window... any time a part of the screen needed to be redrawn by Linux, it would be redrawn and the solid black would go away). My XFCE panels were particularly difficult to get to redraw themselves, though, because they don't refresh very often. I'd have to kill/restart the panels instead.
The reason I replaced this card with a mid-range Nvidia wasn't because of the random blacking-out issue, it was actually the card's pitiful performance in Windows 7. I ordered the desktop with suitably powerful specs (6 GB RAM, 6 core 64-bit AMD CPU), so that I could run emulators for the likes of Sega Saturn and GameCube. For the latter, the frame rate would be pretty slow in parts and I suspected the video card was the bottleneck, so I tried replacing it with an Nvidia card I had from my old desktop. This did indeed speed up the frame rate in the emulators by quite a lot (most games run at full speed most of the time), and of course fixed my blacking-out issues in Linux.
The third time I had to deal with an AMD card was on a work PC. This one has an AMD Radeon HD 7400 Series video card, and it really caused nothing but problems.
First, the open source radeon drivers in this case were entirely useless. About half of the time when I booted this computer, it was unusable. I'd end up seeing a completely white screen, with maybe 3 pixels worth of stuff happening at the top of the screen (I think it was the bottom of an XFCE panel, with a workspace switcher applet). It's like the screen resolution was completely wrong and/or scaled up to a ridiculous level. Switching to text mode didn't work either... the screen would go black, but there'd be no prompt (presumably, the prompt was WAY outside the screen borders).
The other half of the time, the display would simply be off-centered. The left edge of the display would be about 1/3 of the way across the monitor, and then it would wrap-around on the right so that the right part of the display was on the left 1/3 of the monitor. Attempting to change the screen resolution within XFCE (using both XFCE's built-in tool, or xrandr directly), would put the monitor into "seizure mode" where it would flicker black and white rapidly.
Installing the fglrx drivers fixed most of my problems, except that AMD feels the need to let me know that my video card isn't officially supported. They placed a watermark in the bottom right corner of my screen, that's rendered on top of everything else the display puts out, that has their logo on it and says "Unsupported hardware". And there's no configurable option where you can say "that's fine, just let me try my own luck using this driver anyway". Nope, to get rid of the watermark, you have to hotpatch the driver binary to basically delete the image out of it, and then reboot. There's a shell script on the Internet that does this - just google "fglrx watermark"
In contrast, I have never seen an Nvidia card that gave me any problems in Linux. The binary drivers for Nvidia have always been absolutely perfect. The only issues I'd ever run into were the times when Fedora would get a new kernel update, and the third party group who package the Nvidia driver lagged behind a day or two in getting their update out. This is largely fixed by using akmod-nvidia instead of kmod-nvidia, though. akmod's automatically rebuild themselves when you update your kernel.
0.0014s.
