Fixing Ubuntu's broken excuse for a login screen

This is fscking unacceptable. Yah, it's slick. All windows-esque. Whatever. I hate it. I'd like to be able to type my user name in, and not have a freaking list of enumerated accounts sitting there on my damn login window. Now get off my lawn *shakes cane*

Today, it finally annoyed me enough that I'd be willing to do whatever was needed to fix it. How about a real display manager?

In a terminal window, run:

$ sudo apt-get install xdm

You'll get a prompt. Select xdm.

Then, log off from your workstation, and hit Ctrl-alt-F1 to go to the text console. Log in with your user account and run the following commands to shut down gdm and start our new, tasty xdm.

$ sudo /etc/init.d/gdm stop

$ sudo /etc/init.d/xdm start

New, ugly but functional login screen. Yay.

By the way, the link to the Debian logo is buried in the xdm configuration file /etc/X11/xdm/Xresources. If you really want to change it, you can edit this config file and/or Bring out the Gimp and start crack-a-lacking.

fin.

Flyback transformers and CRT discharge. OF DEATH.

Last week, our friend Mike was attempting to power an ionocraft with the flyback transformer from an old 15" Gateway CRT. There was a bit of fear (or overdeserved respect) for the high voltage source. I gave a little quick lesson on how to discharge the CRT before diving into the project, but I figured it deserved a little more detail, and that you guys would at least find it interesting.

While it's true that you wouldn't want to simply grasp the exposed anode and yank it off of the CRT, it seems there's a lot of misinformation and urban legends around flyback coils, CRT discharge, and sudden death. People make it sound like you'll surely shatter the monitor if you don't electrocute yourself first. Legend has it that CRTs are fragile, and one false step can turn them into a deadly fragmentary grenade.

First, let me state that the "shock" factor of a monitor or CRT comes mostly from the fact that the CRT itself acts as a giant capacitor. A capacitor is simply two conductors separated by a dielectric. It so happens that the mesh grid, thick glass, and other energized components in a CRT make a pretty good capacitor which can hold a charge for a long time, even when it's not powered on. That part is NOT a myth.

Even if you do get bitten (I've been, only once, and yes, it hurt), the chances of a lethal electrocution are slim to none, so long as you're not touching an ENERGIZED HV coil, such as if the power supply for the monitor or TV is turned on.

As for the "explosion" or "implosion" hazard of CRT monitors? All modern monitors are designed with a mesh or metal layer inside that keeps the CRT from rapidly failing. Frogman and I have tried breaking many CRTs of various sizes and we've never seen any spectacular failures before. The glass is very thick, and you're most likely to break the little vacuum seal nub at the CRT's tail, or shatter the narrow neck than any thing else. It'll simply hiss and be done with. It's pretty boring, really. It's not a bad idea to wear safety glasses when handling a CRT, though. They're made of glass, which can chip even if the hazard of implosion is virtually nil.

Still, one should remain careful when handling CRTs or otherwise poking around inside devices that use high voltage transformers. As always, we can't be held responsible for your mishaps, and a live flyback transformer is nothing to treat lightly. Some can put out tens of thousands of volts, and most aren't current-regulated. They can cause harm.

I'll use my Mac SE/30 (the Blackintosh) for an example of how to safely discharge a CRT. First, you want to make sure it's unplugged and powered off before you even open it.

On the left, the large suction cup device is the anode. It runs back to the high voltage flyback transformer seen toward the upper right of the photo. This Mac hasn't been powered on in a few months, but the CRT may still hold a capacitive charge. The HV transformer in this model might put out 10kV when energized, but only a fraction of that charge, if any, may remain in the CRT itself.

The way to discharge it is to take a jumper wire, attach one end to a metal screwdriver with a well-insulated handle, the other end to the chassis ground of the monitor. You can do this with an alligator-clip jumper wire, or just grab any old wire you have, strip the ends, and make sure it's connected to the chassis and to the metal screwdriver shaft.

Gently pry up the edge of the cup.

Pry up until you can see the anode plugged into the body of the CRT.

And then, make sure the screwdriver touches the anode. You're done.

If you must remove the anode, you can keep using the screwdriver to pop the anode out of the CRT housing. At this point, you can touch the anode, the flyback transformer and the CRT without fear of being zapped. Of course, I wouldn't recommend intentionally touching the HV gear unless you absolutely must (for instance, to replace a damaged CRT or flyback transformer). As a matter of practice, you should just leave the HV stuff alone if you don't have a good reason to be working on it. It's pretty well insulated in newer monitors and TV sets and shouldn't cause you much problem.

It's common practice to re-ground the HV anode if you're tinkering with high voltage experiments such as CCCKC's ionocraft. It's not really a requirement though. Chances are, the energy stored between the corona wire and the ground skirt of the ionocraft isn't even noticeable, but better safe than sorry.

awk over non-interactive ssh sessions

I had trouble wrapping my brain around this one today. I was attempting to grab the second field of ps(1) output to display only the PID of a given process. Of course, if we had pgrep and pkill, this would be a no-brainer. But we don't.

Note, when I use grep on ps(1) I also pipe it through grep -v grep (which ignores any line containing the pattern "grep") so that grepping for some_process doesn't end up like this:

root 751 200 0 Jun 25 ? 3:11 /usr/sbin/some_process -d
axon 2429 222 0 4:54:59 pts/1 0:00 grep some_process

First attempt:

ssh somebox "ps -ef | grep some_process | grep -v grep | awk '{print $2}' "
The output, though, was the whole line out of ps.

root 751 200 0 Jun 25 ? 3:11 /usr/sbin/some_process -d

I attempted escaping the ticks, double ticks, escaped double ticks, double quotes, and all kinds of madness. Nothing was working. I was getting either a whole ps line (as if awk wasn't even there) or syntax errors from awk.

Finally, I ask a co-worker (the biggest shell geek I know) pointed out that it was being frobbed by two separate shells. He gave me a somewhat complicated line to use, but I figured out an easier way. The second shell was interpreting $2, thinking I was referencing a shell argument, and was passing nothing to awk. Solution? Escape $2.

ssh somebox "ps -ef | grep some_process | grep -v grep | awk '{print \$2}' "
751

Hooray! Hopefully this helps some poor sysadmin somewhere when the time comes to reference variables remotely in something like perl or awk.

Rant: Hackerspaces do not foster cybercrime!

Two things pissing me off today. First: Vitriolic and audacious comments on this otherwise awesome article about hackerspaces in STL Today. Some excerpts from the comments:

The authorities need to keep a close watch on these people. Perhaps their source of funding will be hacking bank accounts.

Trying to include teenagers can get complicated. Personally, I feel open access to tools for cyber hacking, learning how to steal passwords, and other mischief can be inappropriate at that age. Even university students get caught up trying to make a name for themselves. [ . . . ] I was a founding member of CCCKC but these are reasons I chose to leave the group. I don't want to be labeled a cyber hacker by association.

Fortunately, there's some sanity and fact-checking in the comments, too.

And then there's news about Forskningsavd (a Swedish hackerspace) getting raided for something completely unrelated to the hackerspace. Further, the seizure of property seems completely bizarre given the stated reason for police intervention.

So, I'm feeling ranty. Here's some background on how my local hackerspace deals with "Cyber hacking and other mischief"

Shortly after CCCKC's grand opening, a series of courses were taught on cyber-security. These four sessions were very popular, covering the basics such as understanding the difference between hubs and switches, and eventually covering powerful tools such as nmap, Hamster & Ferret, Metasploit, and Maltego. The courses provided enough demonstration to scare people into being more cautious while teaching them how to avoid being victimized. Nothing was covered that hasn't been hashed over online a thousand times already, but it was very cool to get a guided tour through the maze of cyber-security and to be able to tinker around in a hands-on lab environment.

Around the same time, locksport also took off. A solid-core door got drilled out, had eye-screws put into it, and became a standing board of different locks to play with. The Lock Picks & BBQ series was also a big hit. People would come out, grill some meat, and then learn about the mechanics of simple locks.

Critical thinkers absolutely love to explore dynamic boundaries, and very few boundaries are as controversial and exciting as the enigmatic balance of attack resistance vs. usability in both physical security (locks and surveillance) and information security (firewalls, encryption and vulnerability exploitation). It's no wonder some of the worlds most intelligent people have dabbled in security. Richard Feynman, for example, picked locks at Los Alamos for fun and pranks.

Now, several hackerspaces are uniting with an international VPN that's going to be much like a digital Capture The Flag game. We're calling this effort "The Warzone Project" and it'll give people a safe, isolated environment to practice their skills in information security systems.

The thing is, there's already a lot of very detailed information on the web and in books when it comes to breaking all kinds of security systems. Demonstrating them in a lab environment gives people a safe place to "get it out of their system" much like Grudge Night at the local drag strip gives teenagers a safe place to race their cars so they aren't endangering people on public roads. The lab environment also allows people to legally learn about more aspects than they could in their own homes, and to take a shot at mastery in defense by understanding both sides of an attack.

"Hackerspaces are about learning, sharing and collaboration."

Folks, every hackerspace takes on a personality of its own based on what the members are interested in. Some hackerspaces focus on electronics or take an art, metal/woodworking and maker approach. Some tend to focus on programming microcontrollers or building robots. Others are busy tackling so many eclectic projects that they don't even have a core focus. They all have some things in common, though: Hackerspaces are about learning, sharing and collaboration.

Writing the code and creating the control infrastructure for a botnet takes dedication and lots of work. Poring through source code, looking for bugs and creating a working exploit is no small feat. It can take years to fully master exactly how locks work and how to manipulate the parts inside. Indeed, learning in a lab environment teaches patience. It teaches respect for the systems. Learning is hard, but it's good for you.

Compare that to the modern criminal reality: Right now, anyone in the world can rent a cadre of botnet computers for just a few dollars and use them to send spam, to host fake bank websites, to obscure their attacks or to use in a massive denial-of-service attack. Anyone can look up the latest zero-day exploits and use them for bad things. Anyone can buy a bump key and start opening about 30% of the locks that key will fit into. Subversion is easy.

If subversion is your goal, you would be silly to waste your time learning all the minutiae of systems from hackerspace denizens. Cyber criminals already know this. Apparently, some people still don't get it.

Update
I thought I'd share a quick list of things we've worked on and had talks about lately at CCCKC:

• Assisting JayDoc, a not-for-profit medical charity for the needy
• Joined more than a dozen hackerspaces live via webcam for the synchronous hackathon.
  
• Projected a game of Tetris onto a wall in downtown KC
• Building, studying and using the MakerBot
• Ran tech support and helped make BarCampKC 2009 a success
• Built a Twitter-bot (that's currently on the fritz)
• Set up a silk-screen lab for emblazoning logos onto things.
  
• Got good press in INK KC
• Set up a MIDI music workstation
• Built a compressed air T-shirt cannon
• Got a bunch of people familiarized with Arduino programming

We also had a few Turbo Talks and demonstrations lately:

• GPSes, computer interfaces for them, and Geoc... "finding things people hid somewhere"
  
• Search engine optimization
• Robotics
• Hacking the car-buying process
• Intro to Craps (the casino game)
• Server/telecom racks

Finally, people come down to work on their own projects when they have time.

• Electronics
• Robotics
• Radio Controlled Toys
• Photography
• Scrapbooking/Crafts
• E-Textiles (like gloves that work with touchscreens, LED embroidery, etc)

These are some of the things people do at hackerspaces.

VirtualBox: full-screen resolution for OpenBSD (FreeBSD?)

One thing I love about VirtualBox is the Guest Additions package, for Windows and Linux guests. It allows you to resize the window and get an instant resolution change to go along with it. When you start playing with some of the more obscure OSes, though, there's no guest additions. This includes OpenBSD.

To get OpenBSD's guest to run X at full-tilt, I had to do some hacking and tinkering. First, I had to set a custom video mode in VirtualBox. Use the VBoxManage utility on the host platform (VBoxManage.exe on Windows, VBoxManage on Linux, /Applications/VirtualBox.app/Contents/MacOS/VBoxManage on OS X) and do the following where [VM-name] is the name of the VM and [WxHxBPP] is the resolution and bit-per-pixel you're running your host OS at, such as 1280x800x16. In my case, my MacBook's native resolution is 1280x800 and I really don't mind running X.org at 16bpp for a guest OS.

VBoxManage setextradata [VM-name] CustomVideoMode1 [WxHxBPP]

Next, boot OpenBSD or FreeBSD in the VM and use the block of text below as your /etc/X11/xorg.conf file. Backup your existing one if it exists. By default, OpenBSD 4.6 doesn't ship with an xorg.conf file, just using the default config. Be sure to modify the Depth, DefaultDepth and Modes toward the end of the configuration file to match the resolution and BPP you set with VBoxManage. As this will be the only resolution and depth in the configuration file, it should be forced to use this mode if it's supported.

Section "ServerLayout"
 Identifier     "X.org Configured"
 Screen      0  "Screen0" 0 0
 InputDevice    "Mouse0" "CorePointer"
 InputDevice    "Keyboard0" "CoreKeyboard"
EndSection

Section "Files"
 ModulePath   "/usr/X11R6/lib/modules"
 FontPath     "/usr/X11R6/lib/X11/fonts/misc/"
 FontPath     "/usr/X11R6/lib/X11/fonts/TTF/"
 FontPath     "/usr/X11R6/lib/X11/fonts/OTF"
 FontPath     "/usr/X11R6/lib/X11/fonts/Type1/"
 FontPath     "/usr/X11R6/lib/X11/fonts/100dpi/"
 FontPath     "/usr/X11R6/lib/X11/fonts/75dpi/"
EndSection

Section "Module"
 Load  "dbe"
 Load  "dri"
 Load  "extmod"
 Load  "glx"
 Load  "freetype"
EndSection

Section "InputDevice"
 Identifier  "Keyboard0"
 Driver      "kbd"
EndSection

Section "InputDevice"
 Identifier  "Mouse0"
 Driver      "mouse"
 Option     "Protocol" "wsmouse"
 Option     "Device" "/dev/wsmouse"
 Option     "ZAxisMapping" "4 5 6 7"
EndSection

Section "Monitor"
 Identifier   "Monitor0"
 HorizSync    31-80
 VertRefresh  30-100
 VendorName   "Monitor Vendor"
 ModelName    "Monitor Model"
EndSection

Section "Device"
 Identifier  "Card0"
 Driver      "vesa"
 VendorName  "InnoTek"
 BoardName   "VirtualBox Graphics Adapter"
 BusID       "PCI:0:2:0"
EndSection

Section "Screen"
 DefaultDepth  16
 Identifier "Screen0"
 Device     "Card0"
 Monitor    "Monitor0"
 SubSection "Display"
  Viewport   0 0
  Depth     16
  Modes     "1280x800"
 EndSubSection
EndSection

When you launch startx, you should get full screen resolution in a huge window, but may need to use the [HostKey]-F key combo to switch to full-screen mode.

Enjoy!

Cyber Monday? How about MAKE some gifts?

This year, I'm planning on building as many gifts as I can. This is why I was so frustrated with Radio Shack earlier this month. So far, I've got three gifts almost completed, all of which are electronic. I start with an experimenter breadboard like the one shown*, then go bananas. Once I have something working the way I like it, I solder it to perfboard.

There are tons of great ideas in books and online. You can always find cool things to assemble yourself at Evil Mad Science, The Maker Shed, Sparkfun or LadyAda.

If you can't solder or don't quite grok electronics, you can try crafts such as woodworking, cooking, leather working, knitting/sewing, or anything else that you put your time, knowledge and heart into. Chances are, it'll mean more to the recipient than a gift card, some clothes, or whatever device you happen to burn your cash on. Maybe donate some of the grip you save to help save lives? Several initiatives are out there to provide clean, drinkable water to those in need. There's local emergency response and hardship relief, hope for cancer patients and a host of other organizations worthy of your help this season.

How about less consumerism and more love? Get excited and make things!

* The circuit on the breadboard is completely bogus. Sorry, peeps. No clues until December 25th!

Mastery through persistence and gradual learning

Who of us haven't wistfully recalled the scenes in The Matrix trilogy where facts and skills were modularized into chunks of data that could be dropped into the human brain within a matter of seconds?

Real life doesn't work that way. Taking an example from the trilogy: Kung-Fu requires individual neurological paths to be gradually awakened, certain muscle groups to be conditioned, and a particular mindset to be adopted. Mastery of Kung-Fu lies far beyond going through its motions. One may "know Kung-Fu" but one cannot master it without persistence; Mastery involves learning many small things over time while conditioning your body and mind to perform all of the physical and mental tasks necessary to the art.

Shift the subject from Kung-Fu to something many readers of HiR can likely relate to: system administration. It's not an individual skill or a trait. It's a mindset that requires a combination of critical thinking and knowledge of tens of thousands of little facts.

Examples:

• Locations of hundreds of little pieces of configuration data
• Names of scores of system commands
• Hundreds of collective options for those system commands
• Syntax of aforementioned configuration data and system commands
• Menu options and other madness for dozens of popular applications and services such as Apache, sendmail, MySQL and ssh to name just a few.

If you work (or play) in a heterogenous environment such as one where AIX, Solaris, Windows, and Linux are all in use, you can see how the system administration mindset can encompass a dauntingly massive array of skills and a mounting behemoth of facts and knowledge. That's where critical thinking comes in. Sysadmins must be resilient and versatile, adopting an attitude of perpetual, gradual learning. Keep this in mind when you decide to meet your challenges with mastery instead of mere performance. No matter what your challenge is, mastery requires the same persistence and gradual learning.

This post was an inevitable one. I've been mulling over the topic for weeks now, and some conversations on Twitter combined with two awesome articles on Staying Sharp and Fake Achievement sealed the deal. Mastery comes only through hard work. It takes practice, dedication, and frequent use of the skills to maintain. Sometimes that maintenance, the "staying sharp" part does seem quite mundane, but it's very important. Use it or lose it.

The person I was talking to admitted lack of command-line skills (hence the reliance on crutch tech), but I happen to know he's got a good head on his shoulders and could choose mastery. Let's say you have a Linux server running Apache and you really want to host 10 different sites on it. You need to use Apache's VirtualHost feature. Will you settle for performing the task with a crutch and move along, or will you put in the effort to truly master Apache (even if only its VirtualHost feature) so that you can do it again easily in the future?

Learning by example is one way to do it. The Twitter conversation that happened yesterday was about the merits of "crutch technology" system management tools such as cpanel, plesk, webmin and virtualmin. By extension, you could include any easy-to-use "wizard" GUI or web app that ultimately makes simple changes to flat configuration files or performs certain changes that could be done by executing system commands: smit (on AIX), Manage Computer (On Windows) and the like.

Crutch tech can be leveraged in the name of learning by example. Tools like smit and virtualmin make changes that can be observed. By simply figuring out what the tools do for a given action, you can extrapolate how the process works. By building on the crutch's examples and reading the documentation, one can master the skill and lose the crutch.

The ones you look up to might make things look easy, but you rarely get to see the years of hard work that went into what they are. This goes for athletes, hackers, racers, physicists and everyone else who has put in the work to master something.