When companies approach me to work on their helpdesks they often ask "is it acceptable to lie to the client?" That's a difficult question I normally try to get out of asking. I'm fairly sure the answer they expect is "no", but everywhere I've ever worked I've been asked to lie to somebody and so saying I won't lie for them straight off seems a bad idea.

Earlier this week I was being interviewed about a helpdesk role involving some Citrix support. I was honest in admitting to not having used Citrix, so the interviewer responded "If you can't fix their problem, just tell them to reboot and they'll go away." In my last helpdesk role I was often forced to lie about the cause of a problem, in that company most problems were caused by bosses refusing to spend money on fixing things.

So I'm wondering, what's the correct answer to "will you lie to clients?" Should I stand up and refuse to lie to clients, or should I just keep quiet and take the money?

You've ended up moderating many Mailman lists across multiple servers, you're losing track of what you're moderating, the emails asking you to moderate posts are either filling up your inbox or getting ignored. Luckily there's a commandline tool which will make your life much easier.

Listadmin is a command line tool to manipulate the queues of messages held for moderator approval by mailman. It is designed to keep user interaction to a minimum, in theory you could run it from cron to prune the queue. It can use the score from a header added by SpamAssassin to filter, or it can match specific senders, subjects, or reasons.

It can handle multiple list servers, using multiple passwords, and in more recent versions can cope with SSL too. To get started you need to edit the .listadmin.ini file in your home directory. Mine looks something like this:

username kaerast@example.org
spamlevel 8
default skip

# example.org server
adminurl http://{domain}/cgi-bin/mailman/admindb/{list}
password "mypassword"
users@lists.example.org
process@lists.example.org
admin@lists.example.org

# example.com server
adminurl https://{domain}/mailman/admindb/{list}

password "myotherpassword"
supporters@lists.example.com

password "mythirdpassword"
staff@lists.example.com

This config files allows us to moderate queues on multiple lists using multiple passwords. With this configured, we can now run listadmin:

kaerast@bennet:~$ listadmin 
fetching data for users@lists.example.org ... nothing in queue
fetching data for process@lists.example.org ... nothing in queue
fetching data for admin@lists.example.org ... nothing in queue
fetching data for supporters@lists.example.com ... nothing in queue
fetching data for staff@lists.example.com ... 

[1/1] ============== staff@lists.example.com =======================
From:     kaerast@dodgit.com                                         
Subject:  test                                                          
Reason:   Post by non-member to a members-only list            Spam? 0  
Approve/Reject/Discard/Skip/view Body/Full/jump #/Undo/Help/Quit [S] ? r
Why do you reject? test messages aren't allowed
Submit changes? [yes]

Newer versions, ie. those in Lenny and Sid can also add and remove members from a list:

kaerast@hiro:~$ listadmin --add-member kaerast@example.com
process@lists.example.com
Ok

Listadmin is available in Ubuntu Feisty (universe) and all Debian versions. Only Debian Lenny and Sid have the add/remove subscribers functionality added.

There's an issue I'm having with mpd, Flash and alsa on Sid. I've yet to discover what the issue actually is, but it means frequent crashes when both mpd and Flash are trying to make noise. Usually it means Iceweasel or Epiphany crashes when some (but not all) flash videos try to make noise, occasionally it's the other way round and mpd crashes. And when mpd crashes, I have to stop Iceweasel, restart mpd and then start Iceweasel again. I've tried running strace on both programmes, but I learn very little I didn't already know - they hang in exactly the same way after trying to access /dev/snd/controlC0.

open("/dev/snd/controlC0", O_RDWR)      = 6
ioctl(6, USBDEVFS_CONTROL, 0xbfee5d88)  = 0
ioctl(6, UI_DEV_CREATE, 0xbfee5d30)     = 0
close(6)                                = 0
open("/dev/snd/controlC0", O_RDONLY)    = 6
close(6)                                = 0
stat64("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=8611, ...}) = 0
open("/dev/snd/controlC0", O_RDONLY)    = 6
close(6)                                = 0
open("/dev/snd/controlC0", O_RDWR)      = 6
ioctl(6, USBDEVFS_CONTROL, 0xbfee5d88)  = 0
ioctl(6, UI_DEV_CREATE, 0xbfee5d30)     = 0
close(6)                                = 0
open("/dev/snd/controlC0", O_RDONLY)    = 6
close(6)                                = 0
stat64("/usr/share/alsa/alsa.conf", {st_mode=S_IFREG|0644, st_size=8611, ...}) = 0
open("/dev/snd/controlC0", O_RDONLY)    = 6
close(6)                                = 0
open("/dev/snd/controlC0", O_RDWR)      = 6
ioctl(6, USBDEVFS_CONTROL, 0xbfee5d88)  = 0
ioctl(6, UI_DEV_CREATE, 0xbfee5d30)     = 0
close(6)                                = 0
open("/etc/group", O_RDONLY)            = 6
fcntl64(6, F_GETFD)                     = 0
fcntl64(6, F_SETFD, FD_CLOEXEC)         = 0
_llseek(6, 0, [0], SEEK_CUR)            = 0
fstat64(6, {st_mode=S_IFREG|0644, st_size=964, ...}) = 0
mmap2(NULL, 964, PROT_READ, MAP_SHARED, 6, 0) = 0xb7f57000
_llseek(6, 964, [964], SEEK_SET)        = 0
munmap(0xb7f57000, 964)                 = 0
close(6)                                = 0
open("/dev/snd/controlC0", O_RDONLY)    = 6
close(6)                                = 0
semget(0x56a4d5, 1, IPC_CREAT|0660)     = 1212423
semctl(1212423, 0, IPC_64|IPC_STAT, 0xbfee6218) = 0
semctl(1212423, 0, IPC_64|IPC_SET, 0xbfee6218) = 0
semop(1212423, 0xbfee63e2, 2

And yes, it really does hang in the middle of that last semop. I'm now stuck as to how to debug this further, or even where to file a bug report.

I love the Debian community, a couple of weeks ago I was having issues with the Postfix package and it's daft Recommends section. Today whilst on IRC somebody else complained and so I took it upon myself to file a bug, and said so on IRC, which led to somebody else suggesting the fix and yet another person actually writing a patch for me to attach to the report. So, within a few minutes we had a nice fix sent off to the Debian BTS.

Our suggested fix? Stop Postfix recommending mail-reader, and instead add "mailx | mail-reader" to the suggests.

Now we wait and see whether the maintainer will accept it. My knowledge of the Debian way of doing things isn't great, but I'm assuming the next step would then be to include it the next time Postfix gets updated on unstable.

I've finally had enough of my vps provider and so am looking for recommendations of a new one. I've heard good things about Bytemark, and their most basic system sounds almost perfect in terms of size, prics and features. I met them at Internet World a couple of years ago, and they were the only hosting provider who actually understood my questions. The one minor problem being their AUP which would cause problems for the small adult site currently being developed on our vps, although if necessary that could be moved elsewhere.

I will of course want to be running Debian Etch on it, none of this "CentOS is really easy to use" rubbish and none of this "We'll let you run everything through a web control panel" rubbish. I'll also want decent outgoing connection speeds from the server, which I'm currently not getting. And finally I want a provider who doesn't get a support ticket about network problems, and responds by logging into my vps as root, rebooting it, and replying "all fixed" - not that I'm bitter and angry with RapidVPS you understand...

Does anybody have any recommendations for me or any reasons I shouldn't go with Bytemark?

I take a very dim view of upstream providers logging into my systems without permission. Upstream providers are there to provide upstream support, and should have no reason to log into my system unless I ask them to. Simply questioning the connectivity issues we've been facing the past few hours does not require them to log in to my system locally as root, and what's more they shouldn't even be able to do that - they don't know the root password. If I had the money I'd move from a VPS to a dedicated server.

Still, it's not quite as bad as the time we had the vendors of a commercial database system in the office, and one of their marketing people logged into our server through an unpublished SQL injection vulnerability in order to check database size without first asking permission. Tech support, I could almost have forgiven for this, but marketing people knowing about this vulnerability and blatantly using it in front of me?! That to me is completely unacceptable.

My main laptop has a rather dodgy wired network card, it no longer grips the cable properly which leads to frequent disconnections (and no, it's not the cable, it's definitely the card). So, I figured it was time to get wireless configured as nicely as Ubuntu does it.

Turns out it's actually quite easy if you know what you're doing, but it could be made easier for those who don't. My main complaint is the process involves a scary time with no network access until you've rebooted.

Personally I'd like to see network-manager-gnome installed and enabled by default for laptops, but we'd then need to consider adding the initial (and future) users to the netdev group (or maybe we could hack it to use sudo whenever changes are made?)

So, with that in mind we cross our fingers and start reconfiguring the system.

aptitude install network-manager network-manager-gnome

allowing it to add and remove other packages necessary to run.

Then we need to add our users to the netdev group in order to allow them to change networks.

Since we're now using a different dhcp client, we might want to make changes to /etc/dhcp3/dhclient.conf. I opted to set the hostname, so that our home router knows who I am.

And finally we need to reboot. Yes I know this is linux and we should never need to reboot, but it really is the easiest option - and this being a laptop you really shouldn't lose much by doing so.

Logging back into Gnome gives us an extra icon in the systray allowing us to switch networks. And doing so has now given a nice stable wireless network connection, although with the WAP currently one foot from the laptop shouldn't it be a stronger signal than 82%?

• Apache2 - 52Mb
• Lighttpd - 2.5Kb
• Reducing memory usage on a cheap vps - priceless!

I'm in the process of testing lighttpd with all of the sites running on our little vps. So far so good, and it's memory usage is tiny!

Our vps is basicly a Drupal/Mailman server, and so I've documented the installation of the Lighttpd/Drupal stack in case anybody's interested. It's a wiki, so is being edited as I go along finding problems but I'll probably make it into a proper article at some point.

We recently had to rename a user account on a Debian Etch system. If you're thinking of doing this then stop right now, don't. It's more hassle than it's worth. However, given you're like me and really want to go ahead with it anyway may I suggest you backup /etc and /var as well as reading through the following:

Crontabs for that user will stop running. The crontab for the old username will remain in /var/spool/cron/crontabs/oldusername so can easily be copied and pasted with crontab -e and the right permissions. I'm tempted to look into bug reports for this, "crontab -u oldusername -e" returns user unknown, which is technically correct but not entirely helpful.

Gnome will stop loading. This is especially true if you move your home directory and/or change ownership. This can be fixed by changing group ownership and/or creating a symlink from the old home directory.

Apache will break. This can be fixed by editing any virtual sites running form the moved home directory, and any /~username links will need changing.

Mail will do something. We weren't running mail on either of the servers we renamed users on, but I'm fairly sure something will need doing.

MySQL usernames will be out of sync. You can manually rename the MySQL user associated with the shell account which will then break other things, or you can leave as is.

Sudo will break. This is bad. This is very bad. If you break sudo and don't have root access through any other method then you lose root access completely. If you do have root access through another method then you are ok to edit sudoers after renaming the account.

Other authentication may break. Shell accounts are often synchronised with samba, ftp servers, mail servers, ldap, nis, nfs and various other server software. This may be done directly by reading /etc/passwd or it may be done by synchronisation scripts. You need to think about what's running on your server before renaming accounts.

I submitted the following entry to the Debian Package of The Day site.

apt-listbugs is a tool which retrieves bug reports from the Debian Bug Tracking System and lists them. It is designed to be run automatically by aptitude during installations and upgrades and if it detects any critical bugs will stop to ask the user what to do:

Retrieving bug reports... Done
Parsing Found/Fixed information... Done
serious bugs of tetex-doc (-> 3.0.dfsg.3-5) <pending>
#345604 - contains non-free documentation
serious bugs of tetex-base (-> 3.0.dfsg.3-5) <pending>
#368968 - tetex-base: License violation in csplain
Summary:
tetex-doc(1 bug), tetex-base(1 bug)
Are you sure you want to install/upgrade the above packages? [Y/n/?/...]

It then allows users to find out more about the specific bugs listed. By answering w, a web-browser is launched offering links to the bug tracking system for each bug.

By answering with a bug number, querybts is run giving details for that particular bug.

After finding out exactly why the packages are listed as having critical bugs, the user can then either decide to continue installation anyway by answering y (the default) or stop immediately by answering n.

apt-listbugs is available in both Debian and Ubuntu. Unfortunately though the server used by this package to retrieve the bug reports has been down the past couple of days.