Running PulseAudio in system mode with TCP listening on Debian Wheezy
On this thin client I've set up, I wanted pulseaudio to run before logging in, and not have any specific users on the machine. System mode was called for.
On Wheezy, pulseaudio is by default configured for per-user sessions. To remedy this, edit /etc/default/pulseaudio, putting PULSEAUDIO_SYSTEM_START=1
Then, edit /etc/pulse/system.pa - this is the file that configures the server when system mode is used, as opposed to /etc/pulse/default.pa. At the end of said file, I added two lines and some comments:
### Enable TCP and CLI load-module module-native-protocol-tcp port=1500 auth-anonymous=1 load-module module-cli-protocol-unix
Please keep in mind that the above tcp line allows access from any host. This is a potential security problem. I restrict access using shorewall and iptables, but an alternative would be the auth-ip-acl option with a list of approved IP's. More here. Restart pulseaudio:
/etc/init.d/pulseaudio start /etc/init.d/pulseaudio restart
The above restart includes "start", because pulseaudio's default script does not start it on "restart" unless it's not already running. Stupid.
Because pulseaudio now runs as the "pulse" user, commands like pacmd are a pain to use. However, as we made sure to load module-cli-protocol-unix above, they are actually usable, you just have to run them as the "pulse" user, and point it at the correct directory.
sudo PULSE_RUNTIME_PATH=/var/run/pulse -u pulse pacmd
To get access to playing sound, you now need to run anything as "pulse"... or you can simply use the TCP socket you made. Edit /etc/pulse/client.conf and set "default-server" to "localhost:1500" or similar:
default-server = localhost:1500
Now set up SSH port forwarding for port 1500, or whichever port you used above, with something like autossh and public key logins, and you've got remote sound playing over an encrypted tunnel. Neat.
Remember to set the default-server for client computers as well.
One-time passwords in Debian Wheezy with libpam-otpw
While public and private keys with decent pass-phrases are an excellent way of logging in securely to a remote system, it's sometimes simply not feasible. Your Android device which normally does the job for you is out of battery, you are in a remote country with only a wired connection in a shady Internet café, or - <diety> forbid - your laptop was stolen while logged in and you desperately need to get on that system right now.
Anyway, one-time passwords, implemented as "opie" in earlier Debian versions, are now available as "otpw". These allow you to generate securely stored single-use passwords that are safe to use "in the field", and even have counter-measures to attacks like a keylogger opening several SSH connections to your host, trying to guess the last character of the one-time password before you type it.
The following guide will disable the use of ordinary passwords, keeping public/private key login enabled, followed by otpw if no key is provided. Thus, you can log in with your key if you have one, without being asked for a one-time password, but if you don't provide one you get the password prompt.
To install this beauty, we need the pam module and the client program:
apt-get install libpam-otpw otpw-bin
Next, we need to configure /etc/pam.d/sshd to use the newly installed module. For my setup, I want to disable normal passwords, so I comment out the common-auth line, then add otpw.
# Standard Un*x authentication. #@include common-auth #OTPW auth required pam_otpw.so session optional pam_otpw.so
/etc/ssh/sshd_config needs some changes too. These are the relevant lines:
ChallengeResponseAuthentication yes PasswordAuthentication no PubkeyAuthentication yes UsePrivilegeSeparation yes
The only really important line is the ChallengeResponseAuthentication one, which is what we'll be using for otpw. Public keys and privilege separation are normally enabled by default, and as I mentioned I wanted to disable PasswordAuthentication, which covers the use of normal account passwords.
Because we changed the config, we need to restart sshd:
# /etc/init.d/ssh restart
Time to generate some one-time passwords:
$ otpw-gen --help One-Time Password Generator v 1.2 -- Markus Kuhn otpw-gen [options] | lpr Options: -h <int> number of output lines (default 60) -w <int> max width of output lines (default 79) -s <int> number of output pages (default 1) -e <int> minimum entropy of each one-time password [bits] (low security: <30, default: 48, high security: >60) -p0 passwords from modified base64 encoding (default) -p1 passwords from English 4-letter words -f <filename> destination file for hashes (default: ~/.otpw) -d output debugging information $ otpw-gen -h 20 -e 48 -p1 Generating random seed ... If your paper password list is stolen, the thief should not gain access to your account with this information alone. Therefore, you need to memorize and enter below a prefix password. You will have to enter that each time directly before entering the one-time password (on the same line). When you log in, a 3-digit password number will be displayed. It identifies the one-time password on your list that you have to append to the prefix password. If another login to your account is in progress at the same time, several password numbers may be shown and all corresponding passwords have to be appended after the prefix password. Best generate a new password list when you have used up half of the old one. Enter new prefix password: Reenter prefix password: Creating '~/.otpw'. Generating new one-time passwords ... OTPW list generated 2013-01-24 23:17 on slave 000 csce stub neat rope down 016 keep ness mine mock bile 001 pubs ever judo pert kemp 017 blip stan nana file shaw 002 ecsc bone hare hiss make 018 serb ills swam torn rump 003 page type owen dark lent 019 avid bran avid amps lair 004 unto hype fits bets loco 020 putt rout disc gogh bile 005 kits hard sums lime sore 021 hand rash rigs eels vain 006 foci path call spat tins 022 ship what loos chin pine 007 vote sold book gait name 023 yolk mont pubs main kilt 008 band cone draw mats fact 024 para must mala curd tire 009 oboe mill hair chad mont 025 pope slid olds ores dive 010 maps head frog eden teal 026 bony leas bcci jerk need 011 chas memo ives duck revd 027 womb pahl bird ruby naff 012 graf gosh rays roar pour 028 obey bear iona area gain 013 slab sons damn dell pass 029 sort jazz sega rigs onus 014 erik rags tact roar rags 030 lost lump cubs seat film 015 bees aces thee pump kant 031 aura road funk laid hibs !!! REMEMBER: Enter the PREFIX PASSWORD first !!!
Now you should be good to go. The next time you connect, you'll be asked for one, or three, one-time passwords. Three passwords are requested when multiple logins happen simultaneously and other potentially suspicious situations. See /usr/share/doc/otpw-bin/otpw.html for details.
REMEMBER: The password you typed as your "prefix password" has to be entered before the password otpw asks for. If my prefix password was "hello", and the application asked for password 031, I'd enter "helloauraroadfunklaidhibs". Spaces can be typed if you want, but they are ignored.
This is what a typical login looks like for me.
$ ssh home.sweet.home -l bolt Password 026: <This would be hellobonyleasbccijerkneed if my prefix password was still "hello"> Linux home.sweet.home 3.2.0-4-686-pae ..........
That's about it. Remember there is no reason your prefix password needs to match your actual password on that system. They have no relation. It is a good idea to choose a different prefix password, especially if you happen to have "sudo" installed and set up for your user, so you're not typing a password that can potentially make you root to log in from a shady web café. Someone just might take over your machine.
Bugs
There is, at the time of writing, a bug in Debian Wheezy preventing the "session optional pam_otpw.so" line from displaying a count of your remaining one-time passwords upon a successful login. Until that is resolved, you might want to add the small snippet Wolfgang Kroener posted on the bug to your login scripts.
CD-ROM Raspberry Pi case
Components
- Plextor UltraPlex 40 Max SCSI CD-ROM (faulty)
- Asus WL-330N3G wireless client
- Vanson Twin-USB Power Adaptor (2A, 5V, model SMP-600A005USB)
- A power cable, a short HDMI extension cable, an audio cable, an IDE cable and some other wires
- Some memory heatsinks for the Pi
- Some plexi glass
- Two 2N3904 NPN transistors, two 0.25W 300 ohm resistors
- A Raspberry Pi model B, rev. 1
- Probably some more stuff that I forgot about
What, why, how?
I decided the Raspberry Pi hanging around in the livingroom, mostly running pianobar while connected to the stereo, needed a case. It was already divided into several components connected by random, curled up cables and it wasn't pretty. The Raspberry Pi may look small and convenient, but that's just until you realize you need a power supply, wireless capabilities and whatever else you expect to find in a computer.
Anyway, I had an old Plextor CD-ROM in the parts bin and decided to try and use it as the new home for my Pi.
Current state
- The Pi works and runs quite cool
- Power is connected to the Pi through the 5V and GND GPIO pins, as a USB cable on the power connector side would poke out of the case. Also, they're soldered to the bottom of the PSU, saving one USB port for other use.
- The Pi and the power supply are both mounted on plexiglass, for insulation, which in turn is attached to the case
- Wireless is offloaded through the Asus wireless device, making the Pi think it's connected to my network via cable
- Sound output on the front of the case works, volume control works
- The play and stop/eject buttons on the front are connected to GPIO, and clicks are registered, though I haven't figured out what I want them to do
- The DISC and ON/BUSY leds on the front work and are controlled by software
- USB is available on the back with a modified cable which fits the analog audio connector at the back
- All GPIO pins are available on the SCSI connector at the back
- HDMI on the back
- Memory card peeks out about two millimeters through a slot on the right side of the case (can be seen at the left in the last image)
- Runs Raspbian
GPIO
As stated above, the GPIO ports are all available on the SCSI connector on the back of the CD-ROM. I plan to do something interesting with them later. However, I am already using some of them internally. Firstly, I power the Pi using the 5V and GND pins instead of the micro USB port. I also use two pins for the front lights, and two pins for the front buttons. I wrote a small python script to control these for now. Currently, the "disc" light lights up unless a button is pressed (for testing the buttons), and the "on/busy" light lights up randomly based on the load. If the load is >=1.0, it will stay on constantly, otherwise it blinks simulating random CD-ROM reads.
To wire these up, I gutted a USB cable to provide ground to the buttons and power for two 2N3904 transistors. Since the Python GPIO library for the Pi now has pull-up functionality, the pin from the Pi can go directly on the other connector of the button. No additional components needed. For the lights, I used the 2N3904 transistors to provide sufficient current without stressing the Broadcom chip onthe Pi. I connected their base to the GPIO pins. Power is provided from the gutted USB cable and passed through a 300 ohm resistor on the way to the LED's.
Pictures
Using CheckInstall to track custom source downloads on Debian
CheckInstall keeps track of all files installed by a "make install" or equivalent, creates a Slackware, RPM, or Debian package with those files, and adds it to the installed packages database, allowing for easy package removal or distribution.
Use CheckInstall instead of just running "sudo make install", as that will likely put files all over the filesystem, with no easy way of removing them if things go wrong. If in the future you try to install a package that contains the same file as the software you are compiling, you will receive errors and the software you compiled may stop working.
(In fact, checkinstall can keep track of files modified by any command line, not just a "make install", so you can use it for any type of installation task outside of apt, and it will keep track of the installation in the package manager.)
Installation
aptitude install checkinstall
Usage
Instead of:
make install
Run:
checkinstall
When called with no arguments, checkinstall will call "make install". If you need other arguments, they can be supplied:
checkinstall make install_package
The installed package can then also easily be removed:
dpkg -r <package>
Use CheckInstall with auto-apt
You can use auto-apt when you want to build a simple package from source with checkinstall. You need to have auto-apt installed!
Instead of:
./configure
Run:
auto-apt run ./configure
If the dependencies are available, a dialog box opens and ask you to install them
The rest remains the same:
make
checkinstall
Pausing and continuing a process on Linux
If you want to pause a process while you do something else, like for instance stop a heavy file operation while you're just moving some stuff around quickly, there are two signals to pay attention to: STOP and CONT.
STOP will pause a process (not actually stop it - it doesn't die)
CONT continues a stopped process, and does nothing if the process isn't stopped.
An easy way to experiment with this is to start xeyes:
$ xeyes & [1] 26114
In this case, xeyes got the Process ID (PID) 26114. You can use "ps" to find Process ID's of running processes.
Xeyes is an application that shows two "eyes" on the screen, with eyeballs following your mouse pointer around.
To pause this process I use, in my case "kill -STOP 26114". Notice the eyes stop moving to follow the mouse pointer. "kill -CONT 26114" resumes the application.
bash time limit on commands
Several programs, like "timelimit" and "timeout", exist to prevent a process from running for too long.
However, if you want to do this on a box where neither is installed, there's a way to do so with bash alone.
Based on the original script I found at pixelbeat.org...
#!/bin/sh
# Execute a command with a timeout
# Author:
# http://www.pixelbeat.org/
# Notes:
# If the timeout occurs the exit status is 128.
# There is an asynchronous (and buggy) equivalent of this
# script packaged with bash (under /usr/share/doc/ in my distro),
# which I only noticed after writing this.
# I noticed later again that there is a C equivalent of this packaged
# with satan by Wietse Venema, and copied to forensics by Dan Farmer.
# Changes:
# V1.0, Nov 3 2006, Initial release
# V1.1, Nov 20 2007, Brad Greenlee
# Make more portable by using the 'CHLD'
# signal spec rather than 17.
if [ "$#" -lt "2" ]; then
echo "Usage: `basename $0` timeout_in_seconds command" >&2
echo "Example: `basename $0` 2 sleep 3 || echo timeout" >&2
exit 1
fi
cleanup() {
{ kill %1 2>/dev/null; }& # kill sleep $timeout if running
kill %2 2>/dev/null && exit 128 # kill monitored job if running
}
set -m # enable job control
trap "cleanup" CHLD # cleanup after timeout or command
timeout=$1 && shift # first param is timeout in seconds
sleep $timeout& # start the timeout
"$@" # start the job
I made a new script in bash, which also returns the correct exit status if the command completed before the timeout:
http://www.dhampir.no/stuff/bash/timeout.bash
Works well for me, at least
Debian and Ubuntu auto-login and Xorg without a display manager
If you have a harddrive password (most laptops do this) or full disk encryption, you might not feel the need for an additional login after your system boots.
On most Debian-based systems, TTY's 1 through 6 are available after boot, while TTY 7 is used for Xorg. Therefore, I like to put my auto-login TTY on TTY 8, so it's out of the way and leaves TTY 1 available for troubleshooting and similar.
Auto-login to Xorg requires two things: The actual auto-login and a script which loads Xorg.
First things first. The autologin.
In the olden days on a Debian system, this was done by adding a line similar to this one in /etc/inittab:
8:23:respawn:/bin/login -f bolt tty8 /dev/tty8 2>&1
This spawns a TTY 8 and logs in as "bolt" (change to suit your needs). It will do so on runlevels 2 and 3.
Now, however, the tool "rungetty" is generally used for this, as it's more flexible and performs the same functions with a cleaner syntax. First, "apt-get install rungetty" to make sure it's there, then add a line similar to the following:
8:3:respawn:/sbin/rungetty tty8 --autologin bolt
Note that on Debian Lenny and older, the version of rungetty has a specific check in code which only allows --autologin to work on tty1. If asked to autologin on another tty, rungetty would silently fail and spawn a normal login tty. This restriction has been removed from Squeeze and onwards.
On Ubuntu 10.10, the tty configuration is not in /etc/inittab. There, you have to add a file called "/etc/init.d/tty8.conf" with the following contents:
# tty8 - getty
#
# This service maintains a getty on tty8 from the point the system is
# started until it is shut down again.
start on runlevel [23]
stop on runlevel [!23]
respawn
exec /sbin/rungetty tty8 --autologin bolt
I basically copied tty6.conf and modified it to make that.
Autostarting Xorg
So by default when you login, both Debian and Ubuntu will leave you with a bash prompt, and very little graphical goodness. Thus, you want your login script to start Xorg, but only if Xorg is not already running, and we're on tty8. Otherwise, switching from Xorg to a console with, for example, ctrl+alt+f1, would cause another attempt to launch Xorg.
Thus I made this script, named ".bash_login", and put it in my home directory.
# ~/.bash_login: executed by bash(1) for login shells.
# include .profile if it exists
if [ -f "${HOME}/.profile" ] && [ -r "${HOME}/.profile" ]; then
source "${HOME}/.profile"
fi
# if we're not root and we're logged in on tty8, we assume a rungetty autologin and start xorg
if [ ! -z "${UID:-}" ] && [ "$UID" != "0" ] && [ -z "${DISPLAY}" ] && [ ! -z "${SHLVL:-}" ] && [ "$SHLVL" == "1" ]; then
if [ "$(tty)" == "/dev/tty8" ]; then
trap "chvt 1; logout" INT TERM EXIT
chvt 8
while true; do
echo "starting xorg"
startx
echo "sleeping 2 seconds"
sleep 2
done
fi
fi
This script will do a few sanity checks, then run Xorg. If Xorg exits, it will sleep 2 seconds and run it again. If the script is told to stop, it will change to tty1, then logout of tty8.
Remote desktop does not support colour depth 24; falling back to 16

rdesktop on Linux will give this warning message when connecting to a Windows machine which has not been configured for 24-bit color RDP connections. This has, amongst other things, the effect of showing some horrible, jaggy desktop icons. See the pictures on the right for reference.
On Vista, Windows 7 and later (?), the solution is simple: Use 32-bit colors (-a 32)
On XP, which doesn't support 32-bit colors, it gets a little more complicated. XP does support 24-bit connections, but this mode is disabled by default because of bandwidth concerns and bad choices.
To fix this problem on XP (nothing needs changing on the Linux or Windows client) you need to access the Local Machine Group Policy editor.
If you're lucky, going to Start -> Run -> "gpedit.msc" will work for you. Type "gpedit.msc" without the quotes (and click "Run").
If that does not open the group policy editor, this is the long way around:
- Start -> Run and type in "mmc"
- Add the Group Policy snap-in by going to File -> Add/Remove Snap-in -> Add -> Group Policy Object Editor -> Add -> Finish (Local Machine) -> Close -> Ok
In the Group Policy Editor, navigate to Local Computer Policy -> Computer Configuration -> Administrative Templates -> Windows Components -> Terminal Services, and double-click on the 'Limit maximum Color Depth' object.
Set the item to "Enabled" and set "Color Depth" to "24 bit"
Click OK, then log in with the remote client. If the changes haven't been applied, reboot the server.
Rejoice with your new, shiny desktop icons and full 24-bit desktop.
OTP (one-time passwords) on Debian Squeeze SSH logins
So, you're out of your secret lair and now you need to log in from a computer you don't trust. After all, every computer you don't administer is most likely full of viruses, malware and probably even a hardware keylogger somewhere along the keyboard cord, right?
So you want to use a one-time password, so that even if someone snatches it, it has already been used and can never be used again.
Fortunately, one-time passwords on Debian is a breeze to set up.
apt-get install opie-server
This will install opie-server, which will drag along opie-client and libpam-opie as dependencies, unless you have them already.
Now you have to choose if you want one-time passwords for every single login, or only the ones happening over SSH
I wanted it only for SSH logins, so I edit /etc/pam.d/sshd (might be named just "ssh" in other distros)
At the bottom of the file, I appended:
auth sufficient pam_opie.so auth required pam_deny.so
This will make your server first ask for your password, then ask for the one-time password if the password is correct. If you want it to not ask for your normal password, comment out the last line of the file, saying "@include common-auth"
"common-auth", in /etc/pam.d, is also the file you have to edit if you want one-time passwords for all logins, not just for SSH. Don't have sshd ask for your normal password if you also use that for FTP connections or other stuff which doesn't also require a one-time password. Your normal password should be unique.
Then you need to enable challenge response authentication in SSH, which is disabled by default in Debian Squeeze. Edit /etc/ssh/sshd_config and locate the line "ChallengeResponseAuthentication no" change this to "yes" and restart sshd
/etc/init.d/ssh restart
Next, all you have to do is set a passphrase for your one-time passwords:
opiepasswd -cf
-c is for console mode, -f is only needed if you're currently logged in remotely, to force opiepasswd to assume the connection is secure.
Enter the passphrase it asks for. This should be some sentence you can easily remember, preferably with upper and lower case and punctuation.
Now you're ready to try it. Connect, enter your password, watch the one-time password challenge appear:
ssh myserver.dhampir.no Password: otp-md5 498 sl8229 ext, Response:
You can generate the one-time passwords using any suitable tool. I use VeJOTP to generate the passwords on my Java phone, which is really neat, but you can also just use "opiekey" to generate passwords and print them out:
$ opiekey -n 10 498 sl8229 Using the MD5 algorithm to compute response. Reminder: Don't use opiekey from telnet or dial-in sessions. Sorry, but you don't seem to be on the console or a secure terminal. Warning: Continuing could disclose your secret pass phrase to an attacker! Enter secret pass phrase: 489: BABY NAN GALL MONA WEST LUG 490: FEND DES WOO RACE BED AQUA 491: GET FAST HECK BELA NONE RAY 492: NINE SUCH CUNY ARID JUNO SOUR 493: DOTE DUG BRED WARN AWRY SAID 494: FAWN ABUT SAY KILL WAVE WATS 495: RASH AMES BLUE SAP DEE GAB 496: JACK DIRE LUCY ROOM JACK RENA 497: FLUE LOAM TICK LAMB ROWS BEST 498: GLIB ELBA POE OUCH ROW LEN
This command generates the 10 next passphrases, counting down from the requested one (498) based on challenge sl8229.
One-time passwords count downwards, because every key is based on the previous ones, and starting at the end of the list, you then can't calculate the "next" (previous) key.
Windows XP activation doesn’t pop up after repair or ghost
Also, how to log on without activating Windows
------------------------------------------------------------
Ghosted a machine to a new harddrive today, as the old one was failing.
Windows activation pops up on the first boot, as is to be expected, but when I clicked "Activate", nothing happened. The activation wizard simply wouldn't continue. And of course I couldn't get in and activate the system normally, because Windows didn't let me log on without activating. Gah!
The solution, it turns out, is the following:
- Start the machine, while repeatedly hitting F8 from just after the initial BIOS image disappears
- Choose "Safe-mode with command prompt"
- When the command prompt appears, type "explorer" and press <enter>
You're in!
Now you need to (re-)install a hotfix, and Internet Explorer 8. Download them on another machine, and put them on a CD, a USB-stick, or whatever you have available. Install the hotfix first.
Hotfix KB946501: http://support.microsoft.com/default.aspx/kb/946501
Internet Explorer 8: http://www.microsoft.com/windows/internet-explorer/default.aspx
The files you need are called (for English Windows XP):
WindowsXP-KB946501-v2-x86-ENU (hotfix)
IE8-WindowsXP-x86-ENU (Internet Explorer 8)
Anyway, after they're installed, reboot and activate as usual.
Worked for me




