There are plenty of arguments for and against Security Through Obscurity – I’m of the opinion that while the benefit for doing it might be slim, actually implementing it doesn’t cause any problems, so why not?
Moving On! The fastest way to upgrade the PHP version on Debian/Lenny “stable” without running into dependency hell is through the dotdeb repositories. Not only does it allow you to upgrade to PHP 5.3.2, you also get the ability to install PHP-FPM through the Debian package manager, instead of having to re-compile PHP from source.
There is one small problem though – once you upgrade using the Dotdeb repository, all your PHP pages have an “X-Powered-By” header included:
If you are serving PHP content using Apache/2 alone, fixing this is relatively simple. Enable mod_headers as follows:
a2enmod headers
Then add the following line to your Virtual Host definition:
RequestHeader unset X-Powered-By
Now reload your Apache configuration and the header information should disappear when you do a full refresh of the page in your browser.
On the other hand, it becomes a little more complicated if you are using Nginx as your public web-server and proxying PHP requests to a backend Apache process. Depending on how your Nginx setup is configured to handle PHP requests, you may need to use one of two approaches:
Approach 1 – Nginx directly serves PHP content by proxying to a PHP/FastCGI server
If you have installed PHP-FPM, you will know that it runs as a service listening for any requests on Port 9000. Hence, you could have Nginx serve PHP content using the following directives:
location ~* ^.*\.php$ {
fastcgi_pass localhost:9000;
fastcgi_param SCRIPT_FILENAME /var/www/mywebsite/$fastcgi_script_name;}
To hide your PHP version, add the following directive to the Nginx configuration:
#Prevent version info leakage
fastcgi_hide_header X-Powered-By;
Approach 2 – Nginx serves PHP content by proxying to an Apache process:
In this approach, the Nginx configuration for serving PHP content looks very different from Approach 1:
location ~* ^.*\.php$ {
proxy_pass http://127.0.0.1:80;
}
The directive for hiding the version information also changes as Nginx is now acting as reverse-proxy:
#Prevent version info leakage
proxy_hide_header X-Powered-By;
Reload your Nginx configuration and check that the changes have taken effect by triggering a full refresh of the page in your browser:
One of the more fully configured VMWare images for Debian on the VMWare Appliance Marketplace is the image provided by Visoracle.
While it does work almost flawlessly out of the box, there is one small problem – the Guest OS doesn’t support Mouse grabbing/ungrabbing by default.
To fix this, add the following line to your /etc/X11/xorg.conf , in the “Section “InputDevice”" for the Identifier “VMware Mouse”:
Option CorePointer
Then hit CTRL+ATL+BACKSPACE to restart X-Windows. Now enjoy the awesomeness of seamless of mouse grabbing/ungrabbing.
The command-line is and will always be the fastest way to administer a remote Linux installation. But whether it’s running a speed test of the server or monitoring AWStats reports only accessible from the localhost, a GUI interface can often come in handy.
The typical recommendation in such cases is to install VNC and a <Insert preferred desktop environment here>. There are a few problems with this:
1. VNC requires you to open an additional port (or two) at your firewall.
2. VNC relies on it’s own user-authentication database and doesn’t support long passwords.
3. Trying to get usable performance out of VNC is a black art in itself.
The smart answer is NX – a remote desktop solution that relies on SSH for authentication, scales to any sort of connection (all the way down to a 56kbps modem link) and supports multimedia and file-sharing support.
I’m not going to talk about how to install NX on Debian/Ubuntu – there are plenty of guides, including this one on the Ubuntu Wiki.
There are a few “gotchas” when it comes to installing FreeNX on a Debian/Ubuntu VPS and it took a while for me to work out the answers. For the reference of anyone else struggling with these problems then, here are my tips:
- When I use the NoMachine NX Client and try to exit a session, the application seems to “hang”:
One of the best features of NX is robust suspend/resume support for sessions. On a default install of FreeNX however, trying to exit a FreeNX session from the NoMachine NX client doesn’t work. The problem is that a couple of dependencies aren’t included. To fix this, run the following commands:
On Ubuntu –
aptitude install x11-utils
On Debian 5 –
aptitude install x11-utils && aptitude install xterm
Now when you try to exit the session you should see the following dialog box:
- I was told that the NX Client could tunnel sound, but all I get is an error message on my VPS. I was lied to!
Actually the lack of sound is a problem of working with FreeNX on a VPS. You need to install a Sound Daemon – specifically the Gstreamer Sound Daemon. To fix this, run the following commands in Debian/Ubuntu:
aptitude install gstreamer0.10-esd
Once this done, go to System > Preferences > Sound and modify your settings as follows:
Now when you click the Test button, you should hear the soothing sound of a test tone on your local speakers. Note that this isn’t guaranteed to get applications like rhythmbox working and I have no idea on how to go about fixing problems like those. Also keep in mind that the volume control applet will still complain about missing plugins and refuse to “unmute” itself.
- I’m able to login via SSH, but trying to login via NX fails.
I’ll begin this section with a big caveat – the fix for this problem does involve reducing the security of your SSH config. Another caveat – this problem appears to be isolated to Ubuntu.
Situation – you have disabled clear text passwords in your SSHD config (i.e PasswordAuthentication no) and only allow Public Key authentication.
Problem – The NX client fails when trying to connect to the Server. If you turn on debug-level logging for SSH, you see the following message in your auth.log:
(nx) Failed login for user=<someuser> from <so.me.I.P>
You know the password for <someuser> is correct and have typed in letter-by-letter 10 times now.
Diagnosis – Tracing the root of this problem is very hard for two reasons – 1) the error message is very generic and can occur in a number of scenarios and 2) It seems specific to Ubuntu. Debian does not require any changes to your SSHD config to get FreeNX working.
Solution – The only solution that I could find after multiple iterations with the SSHD Config is to enable clear text passwords. In other words, open the sshd_config file and change the line
PasswordAuthentication no
to
PasswordAuthentication yes
Reboot the SSH daemon and FreeNX will start working without a hitch.
It is worth noting that enabling PasswordAuthentication does not imply the passwords are sent unencrypted – they are still encrypted using the host key. In addition, you can lock down SSH access to specific users/groups using the AllowUsers or AllowGroups directives in your SSH config.
