Reset Forgotten MySQL Root Password

Have you ever forgotten the root password on one of your MySQL servers? No? Well maybe I’m not as perfect as you. This is a quick how to reset your MySQL root password. It does require root access on your server.

First things Log in as root and stop the mysql daemon. Now lets start up the mysql daemon and skip the grant tables which store the passwords.

mysqld_safe --skip-grant-tables

You should see mysqld start up successfully. If not, well you have bigger issues. Now you should be able to connect to mysql without a password.

mysql --user=root mysql
update user set Password=PASSWORD('new-password');
flush privileges;
exit;

Now kill your running mysqld, then restart it normally. You should be good to go. Try not to forget your password again.

Install Firefox 3 beta in CentOS 5 / RHEL 5

This short howto is about is CentOS 5 which is based on RedHat Enterprise Linux 5, so this should also work on RHEL 5.

I use CentOS 5 as a Desktop OS on office PC, it’s a very stable and working distro even if it doesn’t always have the latest software. This is why I had to manually install the latest Beta Firefox 3.

First off all we need to install compat-libstdc++-33. Otherwise Firefox won’t run.
# yum install compat-libstdc++-33

Then download the latest beta version of Firefox 3 from www.mozilla.com/firefox/all-beta.html and unpack it to /usr/lib

# tar jxvf firefox-3.0b3.tar.bz2
# mv firefox /usr/lib/firefox-3.0b3

Set the link for the binary

# cd /usr/bin
# cp firefox firefox-1.5
# gedit firefox

then replace all ‘firefox-1.5.0.12’ with ‘firefox-3.0b3’
and finally for a desktop menu create a firefox-3.desktop on /usr/share/applications

# gedit /usr/share/applications/firefox-3.desktop

[Desktop Entry]
Version=1.0
Encoding=UTF-8
Name=Firefox 3 beta 3
GenericName=Web browser
Comment=Send and Receive Email
Exec=firefox
Icon=firefox.png
Terminal=false
MimeType=text/html;text/xml;application/xhtml+xml
Type=Application
Categories=Network;Application;X-Fedora;
Comment=Firefox Web Browser
 
thats all, Firefox 3 beta is ready to run with required plugins.
Same steps can be followed for laatest stable Firefox version 2. 

Promote Additional Domain Controller to Primary Domain Controller

In an Active Directory forest, where you have several domain controllers, but one primary domain controller (PDC) - you may think that you must RESTORE or recover this PDC to salvage the domain. In other words, if the PDC fails - is all lost? Nope, not at all. Unless you do not have backup domain controllers. When you promote additional servers on your domain, and make them member DC's in the same forest, then your domain details are available to you - and you simply need to transfer the Operation Master role to another DC - but before doing that - there are the FSMO's - yea, something hardly anyone knows about: FSMO = Flexible Single Master Operation - something your PDC or master of operations - manages. If a PDC - and Global Catalog for that matter - goes offline, a backup DC will generally pickup and juggle traffic for the PDC. But what happens if the PDC crashes altogether, and you need to basically assign a member backup DC the PDC role? FSMO must be transferred to a backup DC before that DC can assume the Master of Operations role. This is done at the command-line level, and you must be careful before you make this call - ONLY do this if you are sure you cannot recover the original PDC because once you do this - you cannot laterr recover the PDC and bring it online. It cannot be added back into the forest at all. So, the FSMO roles and how we transfer these. In a word, you cannot simply transfer the FSMO roles because the PDC is off line and not available to authorize the transfer. However, you 'can' SEIZE the FSMO roles from the original PDC - even with the machine offl line. Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

Open a CMD prompt on the backup DC you want to perform this on. At the command-line prompt, type Ntdsutil and press <Enter>.

C:\WINDOWS>ntdsutil ntdsutil: At this prompt, type roles and press <Enter>: ntdsutil: roles fsmo maintenance: Now type connections and press <Enter>: fsmo maintenance: connections server connections: Now type connect to servername <serverName> where <serverName> is the name of the backup DC you are working on, and press <Enter>: server connections: connect to servername hamddc02 Connected to hamdc02 using credentials of locally logged on user. server connections: At the server connections prompt type q and press <Enter>: server connections: q fsmo maintenance: Now we are going to SEIZE the FSMO roles we want. NOTE: Out of the 5 FSMO roles, we are NOT going to seize the Infrastructure Master. We do not want to put the Infrastructure Master (IM) role on the same domain controller as the Global Catalog server. If the Infrastructure Master runs on a GC server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a GC server holds a partial replica of every object in the forest. For now, we'll seize the following: Seize domain naming master Seize PDC Seize RID master Seize schema master We do this by typig the line shown above. For example, to seize the domain naming master, type seize domain naming master and press <Enter> You will receive a Windows dialog prompting to confirm this move - click <Yes> and then you'll see the attempt to safely transfer the FSMO role, a failure message, and then it will seize the role, assigning it to the backup DC you specified when you connected to the server above. Once you have completed this for the 4 roles, type Quit to exit the utility, then Exit to return to Windows. From the Start menu, select Run and enter dsa.msc and press <Enter>. On the domain that is displayed, right click and select Operations Masters. You should now see that this backup domain controller (HAMDC02 in this case) is not the Operations master. From here you simply re-create the failed domain controller, and promote it - joining it to this existing forest.   NOTE: some great tips found on net The seize command is a rather heavy handed route to undertake and only should happen as a last resort if the usual transfer is not possible. Don't be alarmed though if you need to go down this road. If the DC is limping till it gives up the ghost, try and transfer the roles without delay. In other words, if there is a chance to transfer then, do it otherwise fall back on seizing them. The issue of never returning the same DC back into the AD had concerened me the most especially as it's written everywhere yet with no good explanation as to why. The main reason for it is that the AD will be competing with the downed server for the handling of the RID pool in particular. If this was to occur, any newly created items within AD will not get unique identifiers and start to cause unknown complications when calling on these ID's leading up to an unstable and very confused AD. However, the above rule would only happen if the downed DC was not freshly rebuilt before returning to the domain. If the server _is_ the same one that left, then you can never bring it back into AD and promote it. However, if it's the same server physically yet was formatted and repartitioned with a fresh OS then its not technically the same server as the GUID of the new machine will be different. That's what is referred to when instructed never to bring it back - the GUID. So, when rebuilding you can even use the same netbios/dns name as the original since AD will hand it a new GUID on entry to the directory. This then means that when removing the server (or rebuilding it from a crash) there will still be remnants of it within AD. You will then need to do a metadata cleanup via ntdsutil. To ensure that all records of the original server have been removed from AD, use the DcDiag /v command. If you need to determine which servers are handling each of the 5 FSMO roles, use the "Netdom query FSMO /domain" command available from either the windows 2000 support tools or within the standard 2003 server.

How to add Google meta verification to Joomla

Easy. Simply sign up for Google Webmaster Tools, and choose the meta tag verification option.  Google will then generate a custom meta tag that you need to embed in the template of your Joomla site. If you use multiple templates, you should add this code to all templates and upload. We prefer to make these changes using Dreamweaver (or notepad) and FTP.  But, if for some reason you do NOT have FTP access, you can still make the changes yourself through the Joomla control panel. Just log in and go to site > template manager.  Click the radio box of the template you want to manage and click the EDIT HTML icon in the upper right. A window will open and you can edit the HTML code directly. We recommend you ad the code just above the <head> tag. It should look something like this: <meta name="verify-v1" content="UniqueGoogleID" /> <head>