un-ubuntuing visudo: how to make visudo use vi instead of nano

At some point, Ubuntu decided that it was best to have “visudo” — which refers to the vi editor by name — use the nano editor by default. If, like me, you are trying to edit the sudoers file, and you don’t want to use nano, or if you want to change visudo “back” to using vi (as intended), then read on. Note that this also will change your default editor to vi, or change the default to whatever editor you choose.

visudo takes its cue from the alternatives configuration system, which means it looks to /usr/bin/editor, which itself points to /etc/alternatives/editor.

The Ubuntu way to change the default editor (which will be used by visudo) then is to run

update-alternatives --config editor

That should go something like this:

laptop:~$ sudo update-alternatives --config editor
[sudo] password for obelix:

There are 6 alternatives which provide `editor'.

  Selection    Alternative

          1    /usr/bin/vim.tiny
          2    /bin/ed
          3    /bin/nano
          4    /usr/bin/vim.basic
*+        5    /usr/bin/vim.gnome
          6    /usr/bin/mcedit-debian

Press enter to keep the default[*], or type selection number: 1
Using '/usr/bin/vim.tiny' to provide 'editor'.

Finally, here's what the filesystem structure looks like:

laptop:~$ ls -l /usr/bin/editor
lrwxrwxrwx 1 root root 24 2008-12-17 14:57 /usr/bin/editor -> /etc/alternatives/editor
laptop:~$ ls -l /etc/alternatives/editor
lrwxrwxrwx 1 root root 18 2009-04-23 17:32 /etc/alternatives/editor -> /usr/bin/vim.tiny

laptop:~$ sudo update-alternatives --config editor
[sudo] password for :

There are 6 alternatives which provide `editor'.

Selection    Alternative
1    /usr/bin/vim.tiny
2    /bin/ed
3    /bin/nano
4    /usr/bin/vim.basic
*+        5    /usr/bin/vim.gnome
6    /usr/bin/mcedit-debian

Press enter to keep the default[*], or type selection number: 1
Using '/usr/bin/vim.tiny' to provide 'editor'.

Fixing broken mysql / mysql-server under Ubuntu 9.04 (Jaunty) after a purge

I broke my server attempting to do some clean-up before making bigger changes.   mysql would not restart, and the culprit was something like  ‘apt-get purge mysql-server,’ which deleted the /etc/mysql directory .  Various installs brought back /etc/mysql but without solving the problem:

% sudo apt-get install mysql-server mysql-common

Setting up mysql-server-5.0 (…)
* Stopping MySQL database server mysqld [ OK ]
* Starting MySQL database server mysqld [fail]
invoke-rc.d: initscript mysql, action “start” failed.
dpkg: error processing mysql-server-5.0 (–configure):
subprocess post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of mysql-server:
mysql-server depends on mysql-server-5.0; however:
Package mysql-server-5.0 is not configured yet.
dpkg: error processing mysql-server (–configure):
dependency problems – leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

2009-06-12 17:23:31 status half-installed mysql-server 5.1.30really5.0.75-0ubuntu10.2

In any case, the only way I could get things back running was to copy over the /etc/mysql directory from a working server,  doing

% sudo apt-get remove –purge mysql-server
% sudo apt-get install mysql-server

and rebooting.

Here’s what the /etc/mysql directory looked like after the copy:

/etc/mysql# ls -l
total 16
drwxr-xr-x 2 root root 4096 2009-06-12 17:23 conf.d
-rw------- 1 root root  312 2009-06-12 17:23 debian.cnf
-rwxr-xr-x 1 root root 1198 2009-05-14 05:39 debian-start
-rw-r--r-- 1 root root 4088 2009-03-30 15:18 my.cnf
/etc/mysql# ls -l conf.d/
total 0

So, the copy provided the conf.d directory and the my.cnf file that the re-install failed to (re)create.

I’ve uploaded a copy of the default Ubuntu 9.04 /etc/mysql/my.cnf file here.

And here’s just the active info from my.cnf file
(filtered through egrep -v '^$|^#' my.cnf to remove empty lines and comment lines) :

—–start my.cnf——

port        = 3306
socket        = /var/run/mysqld/mysqld.sock
socket        = /var/run/mysqld/mysqld.sock
nice        = 0
user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket        = /var/run/mysqld/mysqld.sock
port        = 3306
basedir        = /usr
datadir        = /var/lib/mysql
tmpdir        = /tmp
bind-address        =
key_buffer        = 16M
max_allowed_packet    = 16M
thread_stack        = 128K
thread_cache_size    = 8
myisam-recover        = BACKUP
query_cache_limit       = 1M
query_cache_size        = 16M
expire_logs_days    = 10
max_binlog_size         = 100M
max_allowed_packet    = 16M
key_buffer        = 16M
!includedir /etc/mysql/conf.d/

—–end my.cnf——

Recreating that file may help you get mysql back running, as it appears to have been essential for me.

Incidentally, here is a handy search for printing which logfiles have info about your misbehaving program (in this case, mysql):

/var/log# egrep mysql * | awk -F: '{print $1}' | uniq