How to Reset ALL Mambo 4.x - 4.6.x/Joomla 1.0.x-12 User Passwords in 1(10) Sweep(s)

This article explains how to assign an automatically generated passwords to Mambo 4.x/Joomla 1.0.x-12 User Database table. You will need PHPMyAdmin or a similar MySQL Client to be able to be able to execute the following.

Goal: Generate a new set of Passwords to All Mambo/Joomla Users and have a spreadsheet copy of this new set of passwords with corresponding usernames.

Note: The steps below aims to be verbose, so there are other possible ways to do this in a quicker way with less steps, but the broken down concept will always be similar to this,

Step 1.) Run this query (PHPMyAdmin recommended):

SELECT *, SUBSTRING(MD5(RAND()), -8) as password2 from mos_users;

Step 2.) Export the Results to an sql file (With Drop Database Option checked.)

NOTE: (To Export custom query results from PHPMyAdmin, use the "Export" button found in the "Query results operations" and NOT the "Export" link from the top tabs.)

Step 3.) Add a `password2` column to mos_users:

ALTER TABLE `mos_users` ADD COLUMN `password2` TEXT NOT NULL AFTER `params`;

Step 4.) Import the SQL File Generated from STEP 1 into mos_users table

Step 5.) Run the following query against mos_users table:

SELECT *, MD5(password2) as password3 from mos_users;

Step 6.) Export the Results to an sql file.

Step 7.) Add a `password3` column to mos_users:

ALTER TABLE `mos_users` ADD COLUMN `password3` TEXT NOT NULL AFTER `password2`;

Step 8.) Import the SQL File Generated from STEP 5 into mos_users table

Step 9.) Now drop the current password column

ALTER TABLE `mos_users` DROP COLUMN `password`;

Step 10.) Rename password3 column as password.

CHANGE COLUMN `password3` `password` TEXT NOT NULL;

NOTE: The `password 2 column is the unhashed plaintext 8 character passwords. You might want to jot the result of the following query down or save it as CSV for future reference:

SELECT username, password2 from mos_users;

The resultset from the query above will be the copy of username and unhashed passwords. Once copied, you can safely drop the password2 column by:

ALTER TABLE `mos_users` DROP COLUMN `password2`;

How to Install VMWare Server 1.0.3 on Fedora 7

This will be a quick one.. im still very busy with work and somehow stumbled upon setting up VMware on my laptop.. I hope this could help someone.

1. Upgrade your kernel
   Invoke the following command in the console
   

   yum upgrade kernel

   Then edit /boot/grub/grub.conf and make sure that the "default" parameter is set to 0(zero) or is pointing to the latest kernel.
   
   Reboot the system.
   


2. Install the kernel headers and other necessary sources
   This can be done by invoking the following command in the console
   

   yum install kernel-headers

   and
   

   yum install kernel-devel

   then

   yum install xinetd

3. Download VMWare Server from http://www.vmware.com/download/server/, the Serial number can be obtained from the same page. Select the *.tar.gz instead of the RPM.
   


4. Uncompress the VMware-server-*.tar.gz file using the following command
   

   tar xvpf VMware-server-*.tar.gz

   then run
   

   vmware-install.pl

   Proceed until the install script halts on error
   


5. Download the installer patch from http://knihovny.cvut.cz/ftp/pub/vmware/vmware-any-any-update113.tar.gz
   
   Uncompress the archive and run
   

   runme.pl

6. You are set to run VMWare server. In Gnome, VMware is in the "Applications -> Other" Menu, in KDE, it can be found in "KDE Menu -> Lost and Found"
   

For any clarification, just post a comment..

Sharing Hashes between Mambo 4.x and SugarCRM 4.5.1 Using Views

Its been a while since i posted an article, busy months have passed and im still within timeframes and deadlines.. well most of the time real life intervenes eh? anyways heres my article about Sharing Hashes between Mambo 4.x and SugarCRM 4.5.1 Using MySQL Views

MySQL Views is(are) indeed a wonder, too bad its only available to MySQL versions 5 and up (which nowadays arent offered yet by most shared hostings). Its really a timesaver to be able to construct a table out of a select query without having to build one and have it updated for a function to refer on.

In this article, I will outline simple procedures to create a User Table from within a SugarCRM Database which will hook hashes from a Mambo user table, the aftereffect are the following:

• Both Mambo and SugarCRM systems will refer to the same user MD5 password hashes, causing passwords between to be the same
  
• When a User logs into either of the system, he/she will use the same password, and changing the password from the Mambo system will also change the password in SugarCRM without the need to keep it synced

Basically, the following are the prerequisites:

• MySQL 5
• Both Mambo and SugarCRM must reside on the same Database Server Account
• There should be a common user between the system with the same username, this means that there should be a user with the same username that exitst in both User Tables of SugarCRM and Mambo.

Procedures:

1. Set up the View using the following construct within the SugarCRM Database:
   

   CREATE VIEW users_auth
   AS
   SELECT
   `e.id` AS `id`,
   `d.username` AS `user_name`,
   `d.password` AS `user_hash`,
   `e.authenticate_id` AS `authenticate_id`,
   `e.sugar_login` AS `sugar_login`,
   `e.is_admin` AS is_admin,
   `e.status` AS `status`,
   `e.portal_only` AS `portal_only`,
   `e.is_group` AS `is_group`
   FROM
   mambo_database.mos_users d
   LEFT JOIN sugarcrm_database.users e
   on d.username = e.user_name;

   The above query creates a MySQL View named "users_auth" and gets username and password info from the Mambo database and creates it within the SugarCRM database. Examine the query and modify as to your needs
   


2. Next Step is to modify the "SugarAuthenticateUser.php" file located in the sugarcrm/modules/Users/authentication/SugarAuthenticate directory so all select queries pertaining to the sugarcrm.users table will point to sugarcrm.users_auth view you have previously created. These are lines 43 and and 63 and they should appear as follows

   43: $query = "SELECT * from users_auth where...

   and
   

   63: $query = "SELECT * from users_auth where...

Thats it, the concept is much self-explanatory. If you have further specific questions, feel free to post comments and ill cover it in detail

Issues when Tunneling MySQL

If the following error message ring a bell to you:

"ERROR 2013 (HY000): Lost connection to MySQL server during query"

And you have set up SSH tunnelling to secure your MySQL connection, check if you have complied with the following checklist:

1. Is "AllowTcpForwarding yes" set on the /etc/ssh/sshd_config of the MySQL Server? If not, set this directive to yes and restart SSH. It might be necessary to restart the server machine as shutting down SSHD alone will block you out from a remote server as you will have no access except by physically interfacing with it.
   
2. Is SSH on the originating server running on the background specifically the SSH tunneling command you executed? Check this using the command "top" or "ps -ef | grep "ssh"". If you dont see the process you ran to tunnel MySQL, then run it.
3. If you are using the root account to do the tunnel from the originating server, make sure that the "PermitRootLogin" is set to yes on the "/etc/ssh/sshd_config" of the MySQL Server. If this isnt set, set it and restart the SSHD daemon by restarting the server.

This is a sample SSH tunnel command to forward local(originating) MySQL connections to a remote MySQL Server:

"ssh -N -f -g -L 3306:localhost:3306 root@mysql_server.com"

The above command tells SSH to forward all local connections from port 3306 to mysql_server.com on port 3306 and use the root credential to connect. The above command will also run on the background so you may have to "kill" it if you no longer need it to be running.

For more info, visit the following link:
SSH Tunneling on Google.com

Get that "PERL" right!!

How many times have you stumbled upon an error message similar to this one:

foo: bar: not found

But when you checked:

which bar

It showed you that it exists and sitting there staring at you?

The "foo: bar: not found" error message does not indicate that bar could not be found, but rather bar exists but is calling something that could not be found. This is the case with Perl scripts when the script cannot find where Perl is. I have noticed that most of out "out-of-the-box" Perl scripts point to "/usr/local/bin/perl" whereas some of the OS pre-bundled Perl is preinstalled at "/bin/perl", hence, when you run a Perl script, the "foo: bar: not found" pops out the terminal.

If you compile Apache, PHP and PECL packages, then the following errors might ring a bell:

/usr/local/bin/autoconf: /usr/local/bin/autom4te: not found /usr/local/bin/autoconf: /usr/local/bin/autoheader: not found /usr/local/apache2/bin/apxs: not found

and many other variants of the same error.

Solution:

Edit the nearest command which invoked the error, for ex. "/usr/local/bin/autom4te: not found" - the nearest invoker is autom4te. This denotes that probably autom4te is the Perl Script. Edit the file by hand and at the beginning of the script, write down the correct path to Perl.

If at the beginning of the file autom4te says:
#! /usr/local/bin/perl but "which perl" says "/bin/perl" then you have to update paths as necessary.

Well you can always symlink the Perl binary to where most Perl scripts expects it to be. ex:
"ln -s /bin/perl /usr/local/bin/perl"