Installing Ruby 1.9 on CentOS

$ sudo yum groupinstall 'Development Tools' $ sudo yum install readline-devel $ cd /usr/local/src $ wget ftp://ftp.ruby-lang.org:21//pub/ruby/1.9/ruby-1.9.2-p0.tar.gz $ tar xzvf ruby-1.9.2-p0.tar.gz $ cd ruby-1.9.2-p0 $ ./configure && make $ sudo make install
test the installations with
$ruby -v
ruby 1.9.2p0 (2010-08-18 revision 29036) [i686-linux]
Now, just in case the source became unavailable I'm including it here:
ruby-1.9.2-p0.tar.gz
NOTE:
If you're going to use Ruby for Genexus, the version 1.9.2 and above are NOT suported as this date, instead use the version 1.9.1
ruby-1.9.1-p429.tar.gz

					

Updating AsteriskNOW 1.6 to 1.8

If you have installed freePBX version, fist you need to update it

# yum update

Once this is done, we’ll run a yum shell command

#yum shell

> remove asterisk16 asterisk16-core

> install asterisk18-core asterisk18

> ts solve

> ts run

Thats it !!

GeneXus Work With Pattern under gxPortal

Whit this example we’ll show how to create ANY groups under gxPortal, and apply certain privileges, or GRANT privileges to those groups, to perform the basic MODES under Genexus.

That is:

DSP – Display

DLT – Delete

UPD – Update

INS – Insert (Create)

EXP – Export

So, when you “put” a Work With Pattern under the portal, all those Privileges are Guarantee to work automatically.

First Step.

On the Application we are working under the portal, let’s create the following 5 Activities:


WW_List_ALL

WW_EXP

WW_INS

WW_UPD

WW_DSP

WW_DLT

As you can see on the pictures bellow there is a special Activity, that we call WWUsers_ALL which in terms, includes ALL the rest, what this means, is that the “group” that is assigned this Applications has “Admin” privileges, ALL the privileges

WW_ALL

WW_ALL_Activities

Second Step

There is a Procedure that is called by the WW every time they are executed, and its “isAuthorized”

Here’s where we’re going to put some code:

&Authorized = True

LoadContext.Call(&Context)

&Context.Porta_access_DLT = false

&Context.Portal_access_DSP = false

&Context.Portal_access_EXP = false

&Context.Portal_access_INS = false

&Context.Portal_access_UPD = false

//////////////////////// Check GXportal Security /////////////////////////

&GXPConnInf.DBConnection.Type   = GXPDBConnectionType.LAN

&GXPActivity = New GXPActivitySDT()

&GXPActivity.Name   = lower(&GxObject)

&GXPChkSec.Activities.Add(&GXPActivity)

&GXPActivity = New GXPActivitySDT()

&GXPActivity.Name   = !”WWUsers_” + GAMMode.INS

&GXPChkSec.Activities.Add(&GXPActivity)

&GXPActivity = New GXPActivitySDT()

&GXPActivity.Name   = !”WWUsers_” + GAMMode.DSP

&GXPChkSec.Activities.Add(&GXPActivity)

&GXPActivity = New GXPActivitySDT()

&GXPActivity.Name   = !”WWUsers_” + GAMMode.UPD

&GXPChkSec.Activities.Add(&GXPActivity)

&GXPActivity = New GXPActivitySDT()

&GXPActivity.Name   = !”WWUsers_” + GAMMode.DLT

&GXPChkSec.Activities.Add(&GXPActivity)

&GXPActivity = New GXPActivitySDT()

&GXPActivity.Name   = !”WWUsers_EXP” // export Data

&GXPChkSec.Activities.Add(&GXPActivity)  

Call(PGXPCheckSecurity , &GXPChkSec, &GXPConnInf, &GXPStatus )

//////////////////////////////////////////////////////////////////////////

If not Null(&GXPStatus.Id)

&Authorized = False

endif

// Valid Access  /////////////////////////////////////////////////////////

For &GXPActivity In &GXPChkSec.Activities

//msg(‘Name: ‘ + &GXPActivity.Name + ‘ – ProgramName :’ + &GXPActivity.ProgramName + ‘ – Status :’ + &GXPActivity.Status + ‘ – Access :’ +&GXPActivity.Access)

Do Case

Case &GXPActivity.Name = &GxObject

if &GXPActivity.Access  = GAMBoolean.False

&Authorized = False

endif

Case &GXPActivity.Name = !”WWUsers_” + GAMMode.INS

&Context.Portal_access_INS = &GXPActivity.Access

Case &GXPActivity.Name = !”WWUsers_” + GAMMode.DSP

&Context.Portal_access_DSP = &GXPActivity.Access

Case &GXPActivity.Name = !”WWUsers_” + GAMMode.UPD

&Context.Portal_access_UPD = &GXPActivity.Access

Case &GXPActivity.Name = !”WWUsers_” + GAMMode.DLT

&Context.Porta_access_DLT = &GXPActivity.Access

Case &GXPActivity.Name = !”WWUsers_EXP”

&Context.Portal_access_EXP = &GXPActivity.Access

//ExportExcel.Visible = &GXPActivity.Access

//TImportExcel.Visible = &GXPActivity.Access

EndCase

EndFor

//////////////////////////////////////////////////////////////////////////

SetContext.Call(&Context)

After that we are ready to call the WWs from inside the portal

Let’s just analyze it a little bit:

First we reset the “Modes” we’ll be load in the Context later

&Authorized = True
LoadContext.Call(&Context)
&Context.Porta_access_DLT = false
&Context.Portal_access_DSP = false
&Context.Portal_access_EXP = false
&Context.Portal_access_INS = false
&Context.Portal_access_UPD = false

Then we prepare the “Actions” to be checked on the gxPortal

//////////////////////// Check GXportal Security /////////////////////////
&GXPConnInf.DBConnection.Type   = GXPDBConnectionType.LAN
&GXPActivity = New GXPActivitySDT()
&GXPActivity.Name   = lower(&GxObject)
&GXPChkSec.Activities.Add(&GXPActivity)
&GXPActivity = New GXPActivitySDT()
&GXPActivity.Name   = !”WWUsers_” + GAMMode.INS
&GXPChkSec.Activities.Add(&GXPActivity)
&GXPActivity = New GXPActivitySDT()
&GXPActivity.Name   = !”WWUsers_” + GAMMode.DSP
&GXPChkSec.Activities.Add(&GXPActivity)
&GXPActivity = New GXPActivitySDT()
&GXPActivity.Name   = !”WWUsers_” + GAMMode.UPD
&GXPChkSec.Activities.Add(&GXPActivity)
&GXPActivity = New GXPActivitySDT()
&GXPActivity.Name   = !”WWUsers_” + GAMMode.DLT
&GXPChkSec.Activities.Add(&GXPActivity)
&GXPActivity = New GXPActivitySDT()
&GXPActivity.Name   = !”WWUsers_EXP” // export Data
&GXPChkSec.Activities.Add(&GXPActivity)  
Call(PGXPCheckSecurity , &GXPChkSec&GXPConnInf&GXPStatus )
//////////////////////////////////////////////////////////////////////////

and here we check that the actual “program” (work with) it’s authorized to be access under the “current user”, the user who is logged in the gxPortal

Case &GXPActivity.Name = &GxObject
if &GXPActivity.Access  = GAMBoolean.False
&Authorized = False
endif

And on the rest of the “case” we assigned the MODE to the “Context” to be used latter.

At this point pretty much ends up the “automatic” user control of privileges, now we need to proceed to write / apply the rules based on the “Modes”

Third Step

Now we work on the Transaction’s Work With Pattern

Once we’ve applied the Work With Patter, we select the “Modes” on the Main Selection Level of the Pattern.

Screen shot 2009-10-30 at 10.13.37 AM

And now we defined the “Condition” we want to apply for each MODE, for example, for INSERT we want “&Context.Portal_access_INS” to be “TRUE”, so we defined it as shown on the next pictures:

Screen shot 2009-10-30 at 10.16.30 AM

Screen shot 2009-10-30 at 10.16.41 AM

Here you can see an example of how it works with a user logged in with “DSP” privileges

Screen shot 2009-10-30 at 10.40.37 AM

And here with “UPD” privileges, notice the differences, in the previous one all the options were grayed out, on this one the “Edit” it is NOT, so he/she can edit the record

Screen shot 2009-10-30 at 11.41.21 AM

So far everything it’s working fine, but here is where it gets a little bit tricky, take a look at the next images showing the “TABs” on the Work With:

Screen shot 2009-10-30 at 12.42.03 PM

Screen shot 2009-10-30 at 12.42.12 PM

Screen shot 2009-10-30 at 12.42.25 PM

As you can see on the pictures above NONE of the privileges have been applied (by default) on the tabs, in order to correct that, we  have to repeat the same procedure for the MODES on each “TAB” of the work with.

NOTE:

There should be a way to apply the same concepts to the “TRANSACTIONS” inside the gxPortal, but I haven’t try anything yet. Please, let me know if you can figure it out an easy way to apply the privileges through the WW inside the Transactions.

Thanks.

How to install PHP-Soap package

$ yum install php-soap

There were also some updates to some of the PHP packages installed, so these were installed at the same time. After the install was complete, it is needed to restart Apache and the SoapClient class could now be load by PHP.

To restart Apache:

/etc/init.d/httpd –k restart

How To Set Up Database Replication In MySQL

This tutorial describes how to set up database replication in MySQL. MySQL replication allows you to have an exact copy of a database from a master server on another server (slave), and all updates to the database on the master server are immediately replicated to the database on the slave server so that both databases are in sync. This is not a backup policy because an accidentally issued DELETE command will also be carried out on the slave; but replication can help protect against hardware failures though.

In this tutorial I will show how to replicate the database exampledb from the master with the IP address 192.168.0.100 to a slave. Both systems (master and slave) are running Debian Sarge; however, the configuration should apply to almost all distributions with little or no modification.

Both systems have MySQL installed, and the database exampledb with tables and data is already existing on the master, but not on the slave.

I want to say first that this is not the only way of setting up such a system. There are many ways of achieving this goal but this is the way I take. I do not issue any guarantee that this will work for you!

1 Configure The Master

First we have to edit /etc/mysql/my.cnf. We have to enable networking for MySQL, and MySQL should listen on all IP addresses, therefore we comment out these lines (if existant):

#skip-networking
#bind-address            = 127.0.0.1

Furthermore we have to tell MySQL for which database it should write logs (these logs are used by the slave to see what has changed on the master), which log file it should use, and we have to specify that this MySQL server is the master. We want to replicate the database exampledb, so we put the following lines into /etc/mysql/my.cnf:

log-bin = /var/log/mysql/mysql-bin.log
binlog-do-db=exampledb
server-id=1

Then we restart MySQL:

/etc/init.d/mysql restart

Then we log into the MySQL database as root and create a user with replication privileges:

mysql -u root -p
Enter password:

Now we are on the MySQL shell.

GRANT REPLICATION SLAVE ON *.* TO ‘slave_user’@’%’ IDENTIFIED BY ‘<some_password>’; (Replace <some_password> with a real password!)
FLUSH PRIVILEGES;

Next (still on the MySQL shell) do this:

USE exampledb;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;

The last command will show something like this:

+---------------+----------+--------------+------------------+
| File          | Position | Binlog_do_db | Binlog_ignore_db |
+---------------+----------+--------------+------------------+
| mysql-bin.006 | 183      | exampledb    |                  |
+---------------+----------+--------------+------------------+
1 row in set (0.00 sec)

Write down this information, we will need it later on the slave!

Then leave the MySQL shell:

quit;

There are two possibilities to get the existing tables and data from exampledb from the master to the slave. The first one is to make a database dump, the second one is to use the LOAD DATA FROM MASTER; command on the slave. The latter has the disadvantage the the database on the master will be locked during this operation, so if you have a large database on a high-traffic production system, this is not what you want, and I recommend to follow the first method in this case. However, the latter method is very fast, so I will describe both here.

If you want to follow the first method, then do this:

mysqldump -u root -p<password> –opt exampledb > exampledb.sql (Replace <password> with the real password for the MySQL user rootImportant: There is no space between -p and<password>!)

This will create an SQL dump of exampledb in the file exampledb.sql. Transfer this file to your slave server!

If you want to go the LOAD DATA FROM MASTER; way then there is nothing you must do right now.

Finally we have to unlock the tables in exampledb:

mysql -u root -p
Enter password:
UNLOCK TABLES;
quit;

Now the configuration on the master is finished. On to the slave…

2 Configure The Slave

On the slave we first have to create the database exampledb:

mysql -u root -p
Enter password:
CREATE DATABASE exampledb;
quit;

If you have made an SQL dump of exampledb on the master and have transferred it to the slave, then it is time now to import the SQL dump into our newly created exampledb on the slave:

mysql -u root -p<password> exampledb < /path/to/exampledb.sql (Replace <password> with the real password for the MySQL user root!Important: There is no space between -p and <password>!)

If you want to go the LOAD DATA FROM MASTER; way then there is nothing you must do right now.

Now we have to tell MySQL on the slave that it is the slave, that the master is 192.168.0.100, and that the master database to watch is exampledb. Therefore we add the following lines to/etc/mysql/my.cnf:

server-id=2
master-host=192.168.0.100
master-user=slave_user
master-password=secret
master-connect-retry=60
replicate-do-db=exampledb
Then we restart MySQL:

/etc/init.d/mysql restart




 

If you have not imported the master exampledb with the help of an SQL dump, but want to go the LOAD DATA FROM MASTER; way, then it is time for you now to get the data from the masterexampledb:

mysql -u root -p
Enter password:
LOAD DATA FROM MASTER;
quit;

If you have phpMyAdmin installed on the slave you can now check if all tables/data from the master exampledb is also available on the slave exampledb.

 

Finally, we must do this:

mysql -u root -p
Enter password:
SLAVE STOP;

In the next command (still on the MySQL shell) you have to replace the values appropriately:

CHANGE MASTER TO MASTER_HOST='192.168.0.100', MASTER_USER='slave_user', MASTER_PASSWORD='<some_password>', MASTER_LOG_FILE='mysql-bin.006', MASTER_LOG_POS=183;





  • MASTER_HOST is the IP address or hostname of the master (in this example it is 192.168.0.100).
  • MASTER_USER is the user we granted replication privileges on the master.
  • MASTER_PASSWORD is the password of MASTER_USER on the master.
  • MASTER_LOG_FILE is the file MySQL gave back when you ran SHOW MASTER STATUS; on the master.
  • MASTER_LOG_POS is the position MySQL gave back when you ran SHOW MASTER STATUS; on the master.
Now all that is left to do is start the slave. Still on the MySQL shell we run START SLAVE; quit; That's it! Now whenever exampledb is updated on the master, all changes will be replicated to exampledb on the slave. Test it!