New Zealand Linux

From : http://www.freebsd.org/releases/8.0R/relnotes.html

The highlights in the 8.0-RELEASE are the following:

• A new virtualization container named “vimage” has been implemented. This is a jail with a virtualized instance of the FreeBSD network stack and can be created by using jail(8) command.
• The FreeBSD netisr framework has been reimplemented for parallel threading support. This is a kernel network dispatch interface which allows device drivers (and other packet sources) to direct packets to protocols for directly dispatched or deferred processing. The new implementation supports up to one netisr thread per CPU, and several benchmarks on SMP machines show substantial performance improvement over the old one.
• The FreeBSD newbus subsystem is now MPSAFE.
• The FreeBSD TTY layer has been replaced with a new one which has better support for SMP and robust resource handling. A tty now has own mutex and it is expected to improve scalability when compared to the old implementation based on Giant lock.
• [amd64, i386] The FreeBSD Linux emulation layer has been updated to version 2.6.16 and the default Linux infrastructure port is now emulators/linux_base-f10 (Fedora 10).
• The FreeBSD GENERIC kernel now includes Trusted BSD MAC (Mandatory Access Control) support. No MAC policy module is loaded by default.
• The FreeBSD USB subsystem has been reimplemented to support modern devices and better SMP scalability. The new implementation includes Giant-lock-free device drivers, Linux compatibility layer, usbconfig(8) utility, full support for split transaction and isochronous transaction, and so on.
• The FreeBSD CAM SCSI subsystem ( cam(4)) now includes experimental support for ATA/SATA/AHCI-compliant devices.
• The shared vnode locking for pathname lookups in the VFS(9) subsystem has been improved.
• The ZFS file system has been updated to version 13. The changes include ZFS operations by a regular user, L2ARC, ZFS Intent Log on separated disks (slog), sparse volumes, and so on.
• The FreeBSD NFS subsystem now supports RPCSEC_GSS authentication on both the client and server.
• The FreeBSD NFS subsystem now includes a new, experimental implementation with support for NFSv2, NFSv3, and NFSv4.
• The wireless network support layer (net80211) now supports multiple BSS instances on the supported network devices.
• The FreeBSD L2 address translation table has been reimplemented to reduce lock contention on parallel processing and simplify the routing logic.
• The IGMPv3 and SSM (Source-Specific Multicast) including IPv6 SSM and MLDv2 have been added.
• The ipsec(4) subsystem now supports NAT-Traversal (RFC 3948).
• The GCC stack protection (also known as ProPolice) has been enabled in the FreeBSD base system.
• The supported version of the GNOME desktop environment (x11/gnome2) has been updated to 2.26.3.
• The supported version of the KDE desktop environment (x11/kde4) has been updated to 4.3.1.

For more details, please see the Detailed Release Notes.

A list of all platforms currently under development can be found on the Supported Platforms page.

New WordPress came out last Friday, Sorry about the delay updating the script.

This script will update all instances of wordpress that are not the most current. Run it as root, it will make backups in /root/wp_upgrades of both databases and files in case things go wrong.

It will determine if its a WordPress or WordPress Multi User and apply the correct fix.

wget http://b.ri.mu/files/wordpress-upgrade-2.8.6.sh
sh wordpress-upgrade-2.8.6.sh

You may need to change the ownership of the wordpress files after install, I will fix this bug and write it into the script in the next couple of versions.

If you have any bugs or problems with it, please let me know.

A lot of people use postfixadmin, it means email users are in the database, its easy to use, easy to admin. However the setup can be a little tricky for those not used to it.

If you want to have a go doing it yourself, there is a great tutorial here http://rimuhosting.com/knowledgebase/linux/mail/postfixadmin

Today however we had the most exasperating problem trying to get postfix to connect to the database however on one particular VPS. 2 of us sat for over an hour trying to figure out why all the credentials worked fine, but postfix still couldnt connect.

The logs had the following error messages

Nov 5 01:12:40 hostname postfix/trivial-rewrite[8740]: warning: connect to mysql server localhost: Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (40)
Nov 5 01:12:40 hostname postfix/trivial-rewrite[8740]: fatal: mysql:/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table lookup problem
Nov 5 01:12:40 hostname postfix/trivial-rewrite[8741]: warning: connect to mysql server localhost: Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’ (40)
Nov 5 01:12:40 hostname postfix/trivial-rewrite[8741]: fatal: mysql:/etc/postfix/mysql_virtual_alias_maps.cf(0,lock|fold_fix): table lookup problem
Nov 5 01:12:41 hostname postfix/smtpd[8657]: warning: problem talking to service rewrite: Success
Nov 5 01:12:41 hostname postfix/smtpd[8491]: warning: problem talking to service rewrite: Connection reset by peer
Nov 5 01:12:41 hostname postfix/master[8481]: warning: process /usr/lib/postfix/trivial-rewrite pid 8740 exit status 1
Nov 5 01:12:41 hostname postfix/master[8481]: warning: /usr/lib/postfix/trivial-rewrite: bad command startup — throttling
Nov 5 01:12:41 hostname postfix/smtpd[8685]: warning: problem talking to service rewrite: Success
Nov 5 01:12:41 hostname postfix/master[8481]: warning: process /usr/lib/postfix/trivial-rewrite pid 8741 exit status 1

So clearly it was a case of not being able to connect to the MySQL server, but why? the user was fine, the host was fine, everything was checked, and rechecked. Finally I saw an email which touched on postfix being in a chroot, which meant it was unable to access the mysql.sock file (i had already checked permissions on this multiple times by now).

To make a long story short, this is a Debian based box, and the fix is to change the mysql socket to a place that the mail could access it.

/etc/init.d/mysql stop
cd /etc/mysql
mkdir backup # always
cp *.cnf backup/ # backup everything
sed -i s@/var/run/mysqld/@/var/spool/postfix/var/run/mysqld/@g my.cnf # this edits the file inline
sed -i s@/var/run/mysqld/@/var/spool/postfix/var/run/mysqld/@g debian.cnf #changing the socket location
mkdir /var/spool/postfix/var/run/mysqld/
chown mysql /var/spool/postfix/var/run/mysqld/
/etc/init.d/mysql start

This changed the mysql sock into a directory so that they postfix was able to access it, enabling all mail to run freely.