Geert made us aware that MySQL Cluster now provides the possibility to disable arbitration in order to use an external arbitration mechanism. This is a really important feature, because… well, not really, but only because I was the one who designed it
Coming up with the concept and the two parameters Arbitration=WaitExternal and ArbitrationTimeout=n took a few weeks of discussion. Once we agreed on how to do it, I think Jonas coded it in 20 minutes on the mezzanine floor of the Hyatt, Santa Clara. After that MySQL conference I soon resigned from Sun, so I had now idea what then happened to this feature.
read more

A couple of question I get a lot from MySQL customers is “how will this hardware upgrade improve my transactions per second (TPS)” and “what level of TPS will MySQL perform on this hardware if I’m running ACID settings?” Running sysbench against MySQL with different values for per-thread and global memory buffer sizes, ACID settings, and other settings gives me concrete values to bring to the customer to show the impact that more RAM, faster CPUs, faster disks, or cnf changes have on the server. Here are some examples for a common question: “If I’m using full ACID settings vs non-ACID settings what performance am I going to get from this server?”
Let’s find out by running sysbench with the following settings (most are self explanatory – if not the man page can explain them):

Final Results:
So as you can see the difference between full ACID settings and not (on the same server with only those values on the cnf being changed) results in a huge difference in performance on this standard database server. We can now hand this data to the customer and they will know what impact the settings will have on their application’s performance and what to expect when running full ACID vs non-ACID.
More info on using sysbench here:?http://sysbench.sourceforge.net

in this case i altered through the /proc file system or by using sysctl coz many kernel parameters can be altered through the /proc file system or by using sysctl.

Deactivate IP forwarding

#echo "0" > /proc/sys/net/ipv4/ip_forward

if you are not router Make sure that IP forwarding is turned off

Drop ping packets

#echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_all

sometimes many attacker identify host up with ping the ip,you can drop ping packets in order that your machine can’t respon the ping.

root@bsd:~# ping 192.168.182.250
PING 192.168.182.250 (192.168.182.250) 56(84) bytes of data.

_

Ignore broadcast pings

#echo "1" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts


This disables response to ICMP broadcasts and will prevent Smurf attacks. The Smurf attack works by sending an ICMP type 0 (ping) message to the broadcast address of a network. Typically the attacker will use a spoofed source address. All the computers on the network will respond to the ping message and thereby flood the host at the spoofed source address.

Disable source routed packets

#echo "0" > /proc/sys/net/ipv4/conf/all/accept_source_route

Do not accept source routed packets. Attackers can use source routing to generate traffic pretending to originate from inside your network, but that is actually routed back along the path from which it came, so attackers can compromise your network. Source routing is rarely used for legitimate purposes, so it is safe to disable it.

Disable redirect acceptance

#echo "0" > /proc/sys/net/ipv4/conf/all/accept_redirects

Do not accept ICMP redirect packets. ICMP redirects can be used to alter your routing tables, possibly to a malicious end.

Protect against bad error messages

#echo "1" > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses


Enable protection against bogus error message responses.

Enable reverse path filtering

for i in /proc/sys/net/ipv4/conf/*; do
/bin/echo "1" > $i/rp_filter
done


Turn on reverse path filtering. This helps make sure that packets use legitimate source addresses by automatically rejecting incoming packets if the routing table entry for their source address does not match the network interface they are arriving on. This has security advantages because it prevents IP spoofing. We need to enable it for each net/ipv4/conf/* otherwise source validation isn’t fully functional.

Log all spoofed, source routed and redirect packets

#echo "1" > /proc/sys/net/ipv4/conf/all/log_martians


Log spoofed packets, source routed packets and redirect packets.

/*done*/

but after reboot his configuration are reset,so you must edit /etc/sysctl.conf

ex:

(Manual using echo):
#echo "0" > /proc/sys/net/ipv4/ip_forward

(Automatic in sysctl.conf:)
net.ipv4.ip_forward = 0

Ubuntu 10.04 deb http://bos.fkip.uns.ac.id/ubuntu/ lucid main restricted universe multiverse deb http://bos.fkip.uns.ac.id/ubuntu/ lucid-updates main restricted universe multiverse deb http://bos.fkip.uns.ac.id/ubuntu/ lucid-security main restricted universe multiverse Ubuntu 9.04 deb http://bos.fkip.uns.ac.id/ubuntu/ jaunty main restricted universe multiverse deb http://bos.fkip.uns.ac.id/ubuntu/ jaunty-updates main restricted universe multiverse deb http://bos.fkip.uns.ac.id/ubuntu/ jaunty-security main restricted universe multiverse Ubuntu 8.10 deb http://bos.fkip.uns.ac.id/ubuntu/ intrepid main restricted universe multiverse [...]

I have introduced some new people to MySQL recently and had to back track the years to figure out how I learned what I learned about MySQL indexes.  A quick way to get up to speed about MySQL indexes is these three podcasts by Sheeri Cabral.OurSQL Episode 13: The Nitty Gritty of IndexesOurSQL Episode 17: Hashing it outOurSQL Episode 18: De-myth-tifying IndexesThose three episodes do a good job of explaining how indexes work so that you have a better understanding of how MySQL indexes find your data.

Are you doing some datetime manipulation or maybe you are migrating from some database technology to MySQL or possibly using milliseconds?
Here is an example on how to go about it:
Say you have the following date: MAR 16 2008 09:12:51:893AM
SELECT DATE_FORMAT(STR_TO_DATE(‘MAR 16 2008 09:12:51:893AM’,'%M %d %Y %h:%i:%s:%f%p’),’%Y%m%d%k%i%s.%f’); –> 2008031691251.893000

mysql Tue Jun 15 12:32:56 2010 > SELECT TIMESTAMP(a) FROM abc;
+—————————-+
| TIMESTAMP(a) ? ? ? ? ? ? ? |
+—————————-+
| 2008-03-16 21:12:51.893000 |
+—————————-+
1 row in set (0.00 sec)

EllisLab is blessed with two of the greatest communities that can be found anywhere on the internet in ExpressionEngine and more recently CodeIgniter.  Despite being a relative newcomer to the scene, the people attracted to CodeIgniter are among the smartest, most talented and down-to-earth developers around today.  From time to time we want to highlight some of these talented people, and we’ve asked them to lend their voice to ours.  Have your voice.  I hope you enjoy what they have to say as much as I did.

This week, our Community Voice author is Bruce Alderson, known on the forums as madmaxx, who has written a wonderful guide on how he uses subversion with CodeIgniter.  Bruce is an elder web monkey and systems programmer.  He totally digs the craft of building software, making cool stuff, and causing people to laugh so hard liquids are forced from their nose.  He’s currently the Chief Monkey at Discovery Software and author of the not-at-all famous robotpony.ca.  (Go read the one about shaving your yak)

After working with CodeIgniter for a few months (and WordPress for a few years), I?ve settled on a way to set up web projects that works well for development, deployment, and source control. Note that this style of layout only works on systems like Mac and Linux that have useful symlinks.

First, the folder layout

The layout favours a vhost setup, and splits your code and resources out of the CodeIgniter sources. Splitting your stuff from the CodeIgniter stuff lets you link your Subversion repository to theirs, so that you can keep it in sync with their development.

How it’s done

1. Set up your source tree (not including the symlinks or CodeIgniter source) and add to your Subversion repo.
2. Add a svn link to CodeIgniter’s repo (via svn propedit svn:externals, with public http://dev.ellislab.com/svn/CodeIgniter/tags/v1.6.2/) and run a svn update to grab the framework.  See the Subversion docs for details.
3. Copy the CI application folder to the site root (as app), remove the .svn folders, symlink to application, and add it to your local svn repo.
4. Symlink the other site-extras to the public webserver root, and configure your local machine (and public webserver) to point to this root for the domain’s virtual host setup.
5. Alternatively, you can modify the $application_path to point to ../public/app/ (I’m not sure which is better yet).  See the CodeIgniter docs on apps for more details.

You now have a CodeIgnitor project ready for development. You can keep up-to-date with CodeIgniter updates, deploy easily, and get at your code without wading through extra levels of hierarchy.

Discuss this article

EllisLab is pleased to release CodeIgniter version 1.7.2 for ready download.  What’s new?  Among other changes:

• Compatible with PHP 5.3.0
• Added a new Cart Class.
• Improvements to the Form helper
• Added is_php() to Common functions to facilitate PHP version comparisons
• Modified show_error() to allow sending of HTTP server response codes, and all internal uses now send proper status codes.
• Numerous bug fixes

Version 1.7.2 has been baking in the subversion for quite some time, and has been compatible with PHP 5.3.0 since late July, but many users understandably haven’t been running from the in-development version.  While I’d have liked to have had time to add a few more “big ticket” items to this release, making it 1.8, time is a cruel mistress.  Many of our users develop on Macs, and OS X Snow Leopard ships with PHP 5.3.0, so we felt is was more important to push out this stable maintenance release instead of waiting for an even later date – it’s been almost seven months since a refresh, afterall.  But there are still a few good surprises, and welcome changes.  Enjoy!