11.10 has been a bit of a mixed bag. On the plus side it has Gnome 3, giving me a practical (and in my opinion superior) alternative to Unity. On the minus side I had upgrade glitches on both my work and personal machines, and they were unrelated issues! Might be wise to wipe and reinstall for this one (you did separate your home partition when you installed didn’t you :)).
Anyway after getting it working on my work PC (which has an 8400GS), the desktop was quite laggy in both Unity and Gnome3. It was still usable but I didn’t realise how bad it was until I went home and noticed how much smoother my laptop was, with its lowly 2009-era Intel integrated graphics…
The solution was to install the latest 285.05 Nvidia driver, but trust me when I tell you that you do not want the hassle of using the Nvidia installer from the Nvidia website.
It is much simpler to use the X Updates ppa.
So assuming you already have the default binary Nvidia driver installed and activated (nvidia-current), the quick command line solution to your performance woes should hopefully be:
apt-get update && apt-get upgrade
You should notice an update for the nvidia-current package being installed.
That wasn’t too bad was it? :)
As much for my reference as anyone else’s:
sudo -u gdm gconftool-2 --type=bool --set /desktop/gnome/sound/event_sounds false
Found at: http://ubuntuforums.org/showthread.php?t=1756504
My Dell E4300 has an Intel 5100 wifi card and the led blinks constantly. I still don’t understand how Intel can consider blinking the wifi LED during data transfer to be a sensible default. For most people it blinks non-stop which is both uninformative and irritating.
Fortunately blogger Alex Cabal found a solution for Karmic, and his updated solution also works for Natty/11.04. It describes opening a text editor and pasting a couple of lines, however I’m much lazier so here’s the one-line version:
echo 'options iwlcore led_mode=1' >> /etc/modprobe.d/wlan.conf
Of course, the command above must be run as root (
sudo -i), for some reason sudo gave me access denied. You also need to reboot… or you could just unload and reload the module:
modprobe -r iwlagn && modprobe iwlagn
The double ampersand just executes the next command if the previous one succeeded (exit status 0).
As of Ubuntu 11.10 (kernel 3.0.0) the option has to be applied to the iwlagn module, options for iwlcore are ignored. Thus the full solution now becomes:
echo 'options iwlagn led_mode=1' >> /etc/modprobe.d/wlan.conf
modprobe -r iwlagn && modprobe iwlagn
Disclaimer: This article is provided for your information only, and simply following this guide will not make your server “secure”. As the server administrator you are ultimately responsible for its security!
Having recently been through the process of setting up a few Ubuntu LAMP (Linux, Apache, MySQL, PHP) servers lately I thought I’d make an article out of my notes and provide a starters guide to setting up the LAMP stack on Ubuntu.
It goes without saying that the only truly secure computer is one with no network connection, no ports or input devices and is locked in a bank vault, but such a machine is not terribly useful. Regretfully, compromises must be made to allow functionality! Besides presuming insecurity, there are a lot of things you can do to make your server more secure and keep out the vast majority of would-be hackers running port scans, meta-exploit scripts and dictionary attacks.
Before reading this article you should know that it is now quite old and there is a better method – ‘mdadm –assemble –force’ (it may have been there all along). This will try to assemble the array by marking previously failed drives as good. From the man page:
If mdadm cannot find enough working devices to start the array, but can find some devices that are recorded as having failed, then it will mark those devices as working so that the array can be started.
I would however strongly suggest that you first disconnect the drive that failed first. If you need to discover which device failed first, or assemble doesn’t work and you need to manually recreate the array, then read on.
I found myself in an interesting situation with my parents home server today (Ubuntu 10.04). Hardware wise it’s not the best setup – two of the drives are in an external enclose connected with eSATA cables. I did encourage Dad to buy a proper enclosure, but was unsuccessful. This is a demonstration of why eSATA is a very bad idea for RAID devices.
What happened was that one of the cables had been bumped, disconnecting one of the drives. Thus the array was running in a degraded state for over a month – not good. Anyway I noticed this when logging in one day to fix something else. The device wasn’t visible so I told Dad to check the cable, but unfortunately when he went to secure the cable, he must have somehow disconnected the another one. This caused a second drive to fail so the array immediately stopped.
Despite having no hardware failure, the situation is similar to someone replacing the wrong drive in a raid array. Recovering it was an interesting experience, so here I’ve documented the process.