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.
- copy wp-login.php to your theme directory, call it whatever you like
- replace the following lines:
3 * WordPress User Page
5 * Handles authentication, registering, resetting passwords, forgot password,
6 * and other user handling.
8 * @package WordPress
11 /** Make sure that the WordPress bootstrap has run before continuing. */
12 require( dirname(__FILE__) . ‘/wp-load.php’ );
3 Template Name: Your Custom Login/Registration Page
- 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
- Create a page on your site, select the new template, and note down the page ID and slug
- 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 http://yoursite.com/customlogin?action=register, 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.
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:
- 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)
- Install VNC
apt-get install vnc4server
- 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
- Create a password and VNC server should create some configuration files and start up
- Now we need to edit one of the configuration files
vncserver -kill :1
- 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” &
- Save and quit vim
- Start up the VNC server again
vncserver -geometry 1280×1024 -depth 24
- Now you can connect to the server via a VNC client. On windows, you can use TightVNC
- To connect to the server, you want to use IP:1, for example, my server’s IP is 10.0.0.30, then I need to connect to 10.0.0.30:1
- Put in the VNC password when requested by TightVNC and it should bring up the server’s desktop
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):
echo “newpassword” > <nessus_install_dir>/var/nessus/users/<admin_username>/auth/password
My install directory on Ubuntu 10.04 was /opt/nessus
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.
# 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):
Then restart proFTP:
service proftpd restart