Monthly Archives: March 2012

Modifying the existing WordPress login/registration/lost password form

I wanted to make a few changes to the WordPress login page (wp-login.php) but keep all existing functionality.  I didn’t want to mess around with any core WP files.  Sounds like it should be easy…unfortunately not.

Here’s how you can make a copy of the existing wp-login.php, put it in your own theme, and make it useable so you can then go on to modify it however you like.

  1. copy wp-login.php to your theme directory, call it whatever you like
  2. replace the following lines:
      2 /**
      3  * WordPress User Page
      4  *
      5  * Handles authentication, registering, resetting passwords, forgot password,
      6  * and other user handling.
      7  *
      8  * @package WordPress
      9  */
     11 /** Make sure that the WordPress bootstrap has run before continuing. */
     12 require( dirname(__FILE__) . ‘/wp-load.php’ );
      2 /*
      3 Template Name: Your Custom Login/Registration Page
      4 */
  3. If you’re using the vim editor, use the following two lines:
    Otherwise, use whatever find and replace function your editor has to replace $_REQUEST[‘action’] with $_REQUEST[‘do’], and ?action with ?do
  4. Create a page on your site, select the new template, and note down the page ID and slug
  5. Back to the custom login file, do the following in vim (where 591 is your page ID, and ‘login-register’ is your page slug):
    Or if not using vim, replace wp_login_url() with get_permalink(<your page ID>), replace wp-login.php with <your page slug>, and wp_lost_password_url() with get_permalink(<your page ID>).?do=lostpassword

That should be it.  If you now go to that page it should show you the normal WP login form, and the links for registering and lost passwords should also go to your custom page.  The lost password feature will also direct the user back to the custom page to reset their password.


You can now edit the page however you like!


NB: point 3 may seem a bit unenecessary; we’re changing the ?action= to ?do=, however, wierdly, if you leave as-is and post new user registration data to, WP calls the register_post action (which registers new users) before it even loads your custom template, and then it calls it again during your template.  Very bizarre, but changing it works fine.

Accessing a GUI on Ubuntu XenServer VM

If you try and start the GUI on a paravirtualized Ubuntu VM in XenServer, you’ll get the following error:

Primary device is not PCI
(EE) open /dev/fb0: No such file or directory
(EE) No devices detected

Peter Bats from Citrix said the following:
In a paravirtualized world there is no such thing as a physical console (nor is there a physical CPU, physical memory etc). Hence for completely paravirtualized OSes (with a paravirtualized kernel like Xen) there’s no GUI console.

PS: With the upcoming move/approach of something called PV on HVM (Paravirtualized Linux I/O drivers for a HVM machine, that in this was can profit from the latest developments by Intel/AMD at the hardware levels like EPT/NPT etc.) one will have the option to have both. And a hardware console GUI and good paravirtualized I/O.
This is already available for the RHEL/SLES distros, but not for the general Linux kernel or debian based distributions. There’s work underway to get this included into upstream Linux very soon.


In other words, use VNC for now.

To do that:

  1. Install a GUI onto your Ubuntu server:
    apt-get install ubuntu-desktop (for gnome)
    apt-get install –without-recommends ubuntu-desktop (for gnome without libreoffice and some other stuff)
    apt-get install xubuntu-desktop (xfce)
    apt-get install kubuntu-desktop (KDE)
  2. Install VNC
    apt-get install vnc4server
  3. Set the VNC resolution (whatever resolution you want to see on your desktop machine you’ll be using the VNC client on
    vncserver -geometry 1280×1024 -depth 24
  4. Create a password and VNC server should create some configuration files and start up
  5. Now we need to edit one of the configuration files
    vncserver -kill :1
    vim ~/.vnc/xstartup
  6. Change the file to look like the following (Ubuntu 10.04 and 10.10 only, other versions look different):

    # Uncomment the following two lines for normal desktop:
    exec sh /etc/X11/xinit/xinitrc

    [ -x /etc/vnc/xstartup ] && exec /etc/vnc/xstartup
    [ -r $HOME/.Xresources ] && xrdb $HOME/.Xresources
    xsetroot -solid grey
    vncconfig -iconic &
    x-terminal-emulator -geometry 1280×1024+10+10 -ls -title “$VNCDESKTOP Desktop” &
    x-window-manager &

  7. Save and quit vim
  8. Start up the VNC server again
    vncserver -geometry 1280×1024 -depth 24
  9. Now you can connect to the server via a VNC client.  On windows, you can use TightVNC
  10. To connect to the server, you want to use IP:1, for example, my server’s IP is, then I need to connect to
  11. Put in the VNC password when requested by TightVNC and it should bring up the server’s desktop




Changing Nessus root password without GUI

Useful if you’ve forgotten the root password, or managed to make a typo when setting up Nessus.  This works with Nessus 5 (haven’t tested with other versions):

rm <nessus_install_dir>/var/nessus/users/<admin_username>/auth/hash

echo “newpassword” > <nessus_install_dir>/var/nessus/users/<admin_username>/auth/password

My install directory on Ubuntu 10.04 was /opt/nessus

Fixing proFTP overwrite problems in Virtualmin

For some reason, the proFTP configuration in Virtualmin (v3.88) was not allowing files to be overwritten, despite the configuration in /etc/proftpd/proftpd.conf as follows:

# Umask 022 is a good standard umask to prevent new files and dirs
# (second parm) from being group and world writable.
Umask 022  022
# Normally, we want files to be overwriteable.
AllowOverwrite on

# Uncomment this if you are using NIS or LDAP via NSS to retrieve passwords:
# PersistentPasswd off


To solve this, add the following to the bottom of the config file (/etc/proftpd/proftpd.conf):

        AllowOverwrite  on


Then restart proFTP:

service proftpd restart