DISCLAIMER: If you use PHP for building God’s Kingdom, then more power to you. Sometimes you have to do your best with the tool you have been handed. (However, if you have the freedom to swap tools, you should consider trying Python for a future project and see if it’s a better tool.)
My former supervisor, while I was in missions full-time, was adamant about NOT using PHP. I recall him mock-spitting on the floor in distain when asked by a potential recruit about using PHP. At the time, I was shocked!–especially because I was worried that this reaction would turn off the potential recruit from joining missions.
The truth is that anyone seeking to join missions should be willing to work with whatever tools are in use. Also, those who are decision makers should steer the team towards using tools that balance easy-to-learn with fit-to-the-task. Django is the sweet spot for web development, IMHO.
So, as a former PHP fan-boy who now maintains a PHP website, I understand a lot of PHP’s problems. (So, we’re migrating it to Django.) I’ve had pretty strong convictions about this decision for a while now, but this article really cements it. If you’re wondering why NOT to learn/continue to use PHP, read this article:
I use virtual machines often, esp. when the Operating System differs from my host. (Like when I’m stuck on a Windows box and want to code on Ubuntu.)
I use hosted virtual private servers when I need to share them with people via the Internet.
I’d like to use Linux Containers (LXC), because they offer a lighter-weight alternative to virtual machines.
Up til today, LXC has eluded me. Today, I figured it out.
Qasim says, “One of the main focus for Ubuntu LTS was to make LXC dead easy to use, to achieve this. Creating a basic container and starting it on Ubuntu.”
sudo apt-get install lxc
Ubuntu has made this setup sensible defaults, so you can skip a lot of the configuration file tweaking, unless you really want to dive into that much detail.
Creating a Container
sudo lxc-create -t ubuntu -n my-container
It takes a while to create the container the first time. This is because the process has to download and install (in your container) all the packages it needs–as if it were indeed its own separate OS. It’s supposed to be a lot quicker after that, because all the packages get cached.
Changing root password and setting up user accounts
Brian’s video really helped me here. Basically, you can chroot into your container’s filesystem, then run whatever configuration commands you need to run before you start the container.
In this example, I change the root password in my container and create new user unclebob as a sudo-er.
sudo chroot /var/lib/lxc/my-container/rootfs
addgroups unclebob sudo
Starting the container
Brian recommends (wisely) to run your container behind screen, so your terminal session doesn’t get permanently sucked into the container’s black hole.
screen -S session-name sudo lxc-start -n my-container
You can escape the black hole by typing Ctrl-A, d. See my post Screen FTW for more details.
Install the LXC Web Panel
Looks nice. I haven’t played with it much, nor will likely do so, since I now have all the command-line tools I need. But it might come in handy, esp. if I end up having a lot of containers and need to mess with their settings quickly.
- Brian Martin’s very practical, very swift introduction and demo of Linux Containers
- Brian, I owe you a donut! Your trick about using chrootto change passwords in the container was exactly what I needed.
- Human-readable introduction; also talks about LXC Web Panel – Qasim, I owe you a donut, too! I was not aware that Ubuntu packaged LXC so nicely.
I saw a fun article about planetary orbits at http://ensign.editme.com/t43dances.
The author includes the source code at the bottom of the article, but I don’t have Pascal. So, I ported it to Python. Have fun!
[Edit: WordPress doesn't properly format Python code, so I shared it as a Pastie here: http://pastie.org/8151072]
I was shocked today to find out that Linux Mint defaults to OpenDNS nameservers. The technical reason makes sense, but the hush-hush manner in which it was done does not. Sure, they mentioned it in the release announcement, but IMHO it should be much more obvious than that.
I was really shocked when I found that OpenDNS was presenting its certificates when I was trying to access https://dropbox.com. This smacked of a Man-In-The-Middle attack, which lead me to this discussion of OpenDNS in Mint.
The last post there makes in clear that Mint inserts OpenDNS nameservers in the default /etc/resolv.conf and /etc/resolveconf/resolve.conf.d/tail files. So, I commented them out.
Then, just to be safe, I restarted the networking service. Bad idea! My windows reverted to bare X-windows or something strange. After restarting, I restored my “Cinnamon” session and everything came back. (Whew! Now I have to go fix my wife’s box, too.)
So, you do need nameservers, and fallback nameservers. Here’s what I put in those two files, since I’m on Windstream, and I like OpenNIC and Google better than OpenDNS right now.
# Windstream clean DNS servers first.
# OpenNIC as first fallback.
# Google, as second fallback.
I put Google last, because it’s a redirect-type DNS server. If it doesn’t find what you’re looking for, it sends you to a Google search for it. This is normally OK, but not if you’re dealing with sensitive internal server names. Hence, it’s last.
My tests were taking forever. OK, only about 251 seconds (4 minutes), but that’s forever when you only have 11 tests! (In this one app.)
A lot of people talk about how to speed up PostgreSQL, but here it is in a nutshell:
Turn off fsync and full_page_writes in postgresql.conf
Specifically, here’s how I did it on my Linx Mint 13 box:
1. Edit postgresql.conf.
$ sudo vim /etc/postgresql/9.1/main/postgresql.conf
Change these lines and saved:
fsync = off full_page_writes = off
2. Restart postgresql.
$ sudo service postgresql restart
Now, when I run my 11 tests, it only takes 34 seconds. That’s 8x faster!
NOTE: Probably don’t do this on your Production box.
bcfg2 web reports doesn’t require any authentication out-of-the-box. (As of today.) This means that anyone who knows the URL of your bcfg2 web reports can see (and manipulate?) your server and/or clients.
Possible solutions that I didn’t attempt
The settings.py file contains an AUTHORIZED_GROUP setting. It looks like this activates the NISAuth authentication backend. I have no idea what NIS is, so I’m moving on.
The settings.py also includes the standard Django authentication backend, so theoretically, you could hack the views.py and use the @login_required decorator. But I’m feeling lazy today and want an easier solution.
The simple solution: Apache2 HTTP Authentication
I only care about one user: myself. So, I created a password file, using this command:
sudo htpasswd -c /etc/apache2/bcfg2-passwords myusername
Then, I added this block of code in /etc/apach2/conf.d/bcfg2.conf:
<Location /bcfg2> AuthType Basic AuthName "Bcfg2 Web Reports" AuthBasicProvider file AuthUserFile /etc/apache2/bcgf2-passwords Require user myusername </Location>
I did this with:
- Ubuntu 12.04.2 LTS, Precise Pangolin
- 64-bit architecture
- on Rackspace Cloud
- Bcfg2 Version 1.2.2
- HTTPS enabled on my server (don’t forget to do this or your password will be passed in cleartext!)
I also followed these instructions to install bcfg2-web (after installing bcfg2):
Also, thanks to solj and scofflaw on the #bcfg2 IRC channel.
Linux just got shinier for me! I love its command-line tools, and just stumbled upon one that’s new to me. It’s the whatis command. Basically, it tells you whatever the system knows about any type of keyword.
john@marcosmurf:~$ whatis whatis
whatis (1) - display manual page descriptions
I already know that *man* is the manual database. So, just for fun, I ran:
john@marcosmurf:~$ whatis man
man (7) - macros to format man pages
man (1) - an interface to the on-line reference manuals
And, back to the age-old question:
john@marcosmurf:~$ whatis woman
woman: nothing appropriate.