sysadmin

but this confirms it. Bear in mind that upload is server to client. I'm betting on a bad cable between the server and the switch, but we'll see what iWeb says.

Follow-up: They had originally configured the NIC for auto-negotiate which it didn't like. Setting it to 10/full fixed it.

When labelling a new volume, if an existing volume name is entered, subsequent entries are ignored and the original one is attempted each time.

bacula-dir# bconsole
Connecting to Director localhost:9101
1000 OK: bacula-dir Version: 5.2.10 (28 June 2012)
Enter a period to cancel a command.
*label
Automatically selected Catalog: MyCatalog
Using Catalog "MyCatalog"
Automatically selected Storage: File
Enter new Volume name: 10020
Media record for new Volume "10020" already exists.
Enter new Volume name: 10021
Media record for new Volume "10020" already exists.
Enter new Volume name: 10022
Media record for new Volume "10020" already exists.
Enter new Volume name: 99999
Media record for new Volume "10020" already exists.
Enter new Volume name: .
*label
Automatically selected Storage: File
Enter new Volume name: 10021
Defined Pools:
     1: Default
     2: File
     3: Scratch
Select the Pool (1-3): 2
Connecting to Storage daemon File at bacula-sd.redcell.ca:9103 ...
Sending label command for Volume "10021" Slot 0 ...

Workaround: exit the prompt with "." and reissue the label command.

Update: The bug has been fixed and will be corrected in version 5.2.14.

When configuring Mollom for Drupal, you may get the message

The configured Mollom API keys are invalid.

even though your keys are correct.

The problem is most likely that your server's clock is out of sync. An error of more than a couple of minutes will result in this error. 

A day or two ago I upgraded the ports in my jails. This stopped postfix from accepting mail. The problem was that postgrey, which listens for postfix on tcp/10023 stopped running. It produced an error about not being able to bind to ::1. I got it back running again by altering the flags in the startup script (/usr/local/etc/rc.d/postfix) from:

postgrey_flags=${postgrey_flags:-"--pidfile=${postgrey_pidfile}  --inet=10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey  --x-greylist-header=${postgrey_greylist_header}"}

to

postgrey_flags=${postgrey_flags:-"--pidfile=${postgrey_pidfile}  --inet=127.0.0.1:10023 -d --user=postgrey --group=postgrey --dbdir=/var/db/postgrey  --x-greylist-header=${postgrey_greylist_header}"}

This forces binding to the IPv4 port only.

I usually perform a binary update of my jails using

#freebsd-update fetch install #freebsd-update -d /usr/jails/basejail fetch install

This has worked for years. After doing it yesterday I was unable to login to any of my jails and pretty much everything broke. For example logging in using ssh gave logged the error: /bin/sh permission denied

After spending the day on it I have discovered that the upgrade process changed permissions on /usr/jails/basejail to 700. Changing it to 755 fixed everything.

Roundcube comes with a password change module, through it's disabled by default. Configuring it to change passwords on another server's passwd database is another matter. The instructions only cover using chpasswd on a Linux server to update the local password database.

On the mail server:

• adduser roundcube, set a shell and create a home directory.
• visudo, adding roundcube ALL = NOPASSWD: /usr/sbin/pw

On the web server:

• chpass www, assigning a shell to allow logins.
• su www, impersonate www.
• ssh-keygen -t rsa, create an RSA private/public key pair.
• scp /home/www/.ssh/id_rsa.pub roundcube@<em>remotehost</em>/~/.ssh/authorized_keys, copying the public key to the mail server to allow passwordless logins.

The chpasswd driver (/www/roundcube/plugins/password/drivers/chpasswd.php will require modification.

function password_save($currpass, $newpass) { 
    $cmd = rcmail::get_instance()->config->get('password_chpasswd_cmd'); 
    $username = $_SESSION['username']; 
    $handle = popen($cmd, "w"); 
 
    fwrite($handle, "$newpass
"); 
    if (pclose($handle) == 0) { return PASSWORD_SUCCESS; }     
    else { 
        raise_error(array( 'code' => 600, 'type' => 'php', 'file' => __FILE__, 'line' => __LINE__, 'message' => "Password plugin: Unable to execute $cmd" ), true, false); 
    } 
    return PASSWORD_ERROR; 
}

And so will this line in /www/roundcube/plugins/password/config.inc.php

// chpasswd Driver options 
// --------------------- 
// Command to use 
$rcmail_config['password_chpasswd_cmd'] = "ssh roundcube@mailhost sudo pw usermod -n {$_SESSION['username']} -h 0 2> /dev/null";