If you are using the ifcfg scripts in /etc/sysconfig/network-scripts to bring up VLAN sub-interfaces on a NIC and you are getting messages such as:
Bringing up interface eth0.200: Device eth0.200 does not seem to be present, delaying initialization.
instead of
Bringing up interface eth0.200: Added VLAN with VID == 200 to IF -:eth0:-
as you would expect, then make sure that you have the vconfig RPM installed.
If you’re having file conflict problems when running “yum update” on servers with the lxlabsupdate repository for HyperVM (or Kloxo) installed then there’s a simple resolution:
cd /var/cache/yum/lxlabsupdate/packages/
rpm -Uvh *.rpm –replacefiles –replacepkgs
This should fix errors such as:
file /usr/share/man/man1/pcregrep.1.gz from install of pcre-8.02-1.el5_5.1.x86_64 conflicts with file from package pcre-6.6-2.el5_1.7.i386
file /usr/share/man/man1/pcretest.1.gz from install of pcre-8.02-1.el5_5.1.x86_64 conflicts with file from package pcre-6.6-2.el5_1.7.i386
Have you ever deleted everything out of /dev by accident (or even on purpose)? Although it may seem that all is lost or that you have a lot of work ahead of you, it’s actually quite easy to restore on a modern Linux system such as CentOS 5 (or the RHEL equivalent).
The first thing you need to know is that CentOS and Red Hat use udevd, which means that the entries in /dev are dynamically created by the udev daemon and restarting this daemon will force it to re-create everything in /dev, just as it would when you start your computer up. This daemon isn’t controller in the normal way through the /etc/init.d scripts though, all you need to run is:
/sbin/start_udev
This will kill any copies of udev running and then start it back up, re-creating the /dev entries in the process. This seems to be quite safe to do on a production system, but it might be wise to only do this if you really have to, as if you haven’t damaged the contents of /dev, then some of your applications may not take kindly to the contents disappearing.
This will have re-created most of your device nodes in /dev, but there are still a couple of important ones missing, namely those used by device-mapper and LVM. You can get these back with the following two commands:
dmsetup mknodes
vgmknodes
The first of which will re-create entries under /dev/mapper and the second of which will re-create LVM volume group entries under /dev/
Helpfully this will save someone a real headache or even rebuilding/restoring from backup unnecessarily. Just be more careful with rm next time! 
By default HP ProCurve devices (like most switches) use telnet and TFTP (Trivial File Transfer Protocol) for management access, firmware upgrades and config backups. As these are both unencrypted protocols, it is a good idea to switch to using SSH and SCP/SFTP in order to secure your management access and all important configuration, which you can do with the following commands from configure mode:
crypto key generate ssh
ip ssh
ip ssh version 2
ip ssh filetransfer
This generates the keys that SSH requires, forces SSH to use the newer version two of the protocol and enables SCP/SFTP support for copying files to and from the flash.
As soon as you enable SSH filetransfer (basically SCP/SFTP) support then TFTP is disabled, but you have to disable telnet access manually in configuration mode with:
no telnet-server
Apple’s 5.0 release of the fantastic Safari web browser has introduced a feature I’ve been waiting for since discovering it several years ago in a somewhat unstable third party plugin who’s name escapes me and which has been in Firefox for some time – the ability to re-open an accidentally closed tab.
When combined with the “Reopen Last Closed Window” and “Reopen All Windows from Last Session” items under the history menu, Safari now has all the features that I miss from Firefox for when I accidentally hit the cross or on the rare occasions when it just locks up (usually thanks to bloody Adobe Flash Player!).
To use this awesome new feature, just use the normal undo/redo buttons under the Edit menu.
Safari 5.0 also brings back the nice old school progress meter in the background of the address bar. 
Do you want to change the MAC address of a VLAN interface in Mikrotik RouterOS? Are you baffled by the fact that although the VLAN interface has a MAC address property inherited from the parent Ethernet interface, it isn’t editable?
Well, you’re in luck, it isn’t actually impossible to give your VLAN interface a different MAC address to it’s parent interface, you just have to go about it in a somewhat roundabout way by making what is effectively a virtual Ethernet interface and bridging it to the VLAN interface. You then add your layer 3 IP functions to the bridge interface instead of to the VLAN interface.
First, you need to create a bridge and give it a name, then add the VLAN interface who’s MAC address you want to change to the bridge as a port. Finally, set the “auto-mac” property on the bridge to “no” and then change “admin-mac” property for the bridge to be whatever you want your new MAC address to be
/interface bridge add name=newmac disabled=no auto-mac=no admin-mac=”00:00:00:00:00:00″
/interface bridge port add bridge=newmac interface=vlan1
Have you ever wanted to get the Dell Service Tag from a PowerEdge machine that you don’t have physical access to? Well it’s actually quite easy as Dell make this available through the standardised Desktop Management Interface (otherwise known as DMI) framework, so you don’t even have to install any of Dell’s OpenManage tools to view it!
On a Linux system, you just need to run the following as root:
/usr/sbin/dmidecode -s system-serial-number
On a Windows box, you can accomplish the same thing from the command prompt with:
wmic bios get serialnumber
Both of these tools should be installed by default on the respective operating system. If you have some kind of super stripped down installation, then they are available from the vendor’s original media.
Somewhat annoyingly, Dell seem to like to disable Intel’s VT (Virtualisation Technology, sometimes called VMX) in the BIOS on their Dell PowerEdge servers, which means that you can’t use the Xen hypervisor to virtualise Microsoft Windows Server without changing this setting, which requires a reboot of the server to take effect.
You can use omreport from the Dell OpenManage Server Administrator software to check whether or not you have Intel Virtualisation Technology enabled.
If you haven’t got OpenManaged Server Administrator installed, then you can enable the Dell yum repository for CentOS/Red Hat systems and install it with:
wget -q -O – http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
yum -y install srvadmin-base
/opt/dell/srvadmin/sbin/srvadmin-services.sh start
Once you’ve got the Dell OpenManage Server Administrator services running, you can take a look at what processor is installed in your system and what the current BIOS settings are with:
omreport chassis processors
omreport chassis biossetup
The two attributes that you’re looking for are Processor Virtualization Technology (which needs to be enabled) and Demand-Based Power Management (which needs to be disabled).
If you need to change them, then you can do this with:
omconfig chassis biossetup attribute=cpuvt setting=enabled
omconfig chassis biossetup attribute=dbs setting=disabled
Once that's done, then verify the new settings by running omreport chassis biossetup again and then once you’ve rebooted the server you can start taking advantage of the hardware virtualisation provided by Intel’s Virtualisation Technology.
In April’s Plesk 9.5.1 update (following on from 9.3.x – apparently Parallels can’t count so just skipped 9.4.x and 9.5.0 entirely…) they managed to seriously break one of the great Plesk 9 features for Postfix users… greylisting!
One of the big improvements when Plesk 9 was released (apart from ditching QMail!) was that it no longer relied upon unsupported third party software such as QGrey to add greylisting features. The big benefit of this was that the greylisting was tied in the with authentication of mail users, so users who authenticated to your SMTP server in order to use it as a relay automatically bypassed the greylisting filters.
The use of third party greylisting in Plesk 8.x was the source of much frustration from users who were trying to send e-mails and were getting unhelpful error messages from their e-mail clients. This puts server administrators in a difficult position; deal with the user complaints, or disable greylisting and put up with a massive increase in spam e-mail.
In Plesk 9.5.1 this feature mysteriously stopped working. At first Parallels claimed that greylisting was working as designed, but then admitted that it was a bug and they would fix it. The Plesk 9.5.2 release came and went with no fix and no word from Parallels. In the end, it was well over a month from Pleks 9.5.1 being released and the bug first being reported to a patch being available.
The fix that they have released isn’t released as a hotfix and so doesn’t show up in the normal Plesk update process either from the command line auto-installer or the Plesk web GUI’s udpate manager, nor is it applied as part of a fresh install. It’s not even on the Parallels Knowledge Base, you have to go on their forums and find it in a thread by a Parallels member of staff known as “IGorG” called “Workarounds” in the “Parallels Plesk Panel 9.5 for Linux/UNIX Suggestions and Feedback” forum.
Even once you have located the ZIP file containing the patched code and got your forum login to work long enough for you to download it without getting a “Can’t create new user ” error, Parallels have only release the fix for certain platforms (in particular, CentOS 4.x and 5.x both 32-bit and 64-bit as well as Debian 5 64-bit only) and they don’t seem to have any intention of releasing the patch for the other Linux/UNIX platforms supported by Plesk 9.x (SuSE, openSuSE, FreeBSD, Fedora, Debian 3.x & 4.x, Debian 5.x 32-bit, Ubuntu or CloudLinux).
If you are lucky enough to be on one of the supported platforms for which they have released a patch then you can download the ZIP file with the new postfix-queue files from the “official” post on the Parallels forum at http://forum.parallels.com/showpost.php?p=413387&postcount=62
Once you have copied it onto your server and extracted the contents, you should find several folders which correspond to the patched platforms (Cos4x32, Cos4x64, Cos5x32, Cos5x64 and Deb5x64), each of which has a fixed copy of the “postfix-queue” binary inside.
Back up your current postfix-queue from “/usr/lib/plesk-9.0/postfix-queue” (32-bit copies of Plesk) or “/usr/lib64/plesk-9.0/postfix-queue” (64-bit copies of Plesk) to somewhere safe and then copy the postfix-queue file from the appropriate directory over the /usr/lib/plesk-9.0/postfix-queue or /usr/lib64/plesk-9.0/postfix-queue file and restart the Postfix service.
Your authenticated users should now be able to send e-mail again without having to wait for the greylisting timers.
iOS 4 (previously iPhone OS 4.0) Gold Master has been released to developers and I am happy to report that the brilliant Worms game finally works with it on the 3GS, unlike in all of the iPhone OS 4.0 beta releases where it would launch but return you to the springboard straight away then just sit in the list of open apps in the multitasking taskbar…