Copy/Transfer Files Between Two Linux Servers Using SCP

Ini hanyalah artikel copas, jadi buat para pembaca dilarang protes ya,…. !!!

The other day we ran into a good problem that our site has grown and we are in need of a new server. So we ordered the server and now we need to transfer all the files from the old server to the new one. But rather than downloading all the files to our local machines then re-cuploading them to the new server, we’re going to show you how you can skip the middle man and transfer files from server to server.

The only requirements is that you need to have SSH access to both servers.

We’re going to be using the Linux command scp which stands for secure copy.

We’re going to be using the following options:

  • r = recursively copy entire directories
  • C = compression enable
  • p = preserves modification times, access times, and modes from the original file


Also, if you’re going to transfer a lot of data between the webservers, you probably want to add the nohup command too. nohup runs a command even if the session is disconnected or the user logs out. Another bit you can add is trailing ampersand (&) to the end the command to launch it in the background and get your command prompt back right away.

Hope this helps someone as much as it did me today.

Cara Reset the MySQL root password on Ubuntu Linux

Ada kalanya mungkin kita lupa password root mysql di vps kita 😀 Nah ini dia caranya buat reset password root mysql kita 😉 Check it out yachhh…..

Stop the MySQL Server.

Start the mysqld configuration.

Login to MySQL as root.

Replace YOURNEWPASSWORD with your new password!


Done !!

Increase PHP script execution time with Nginx

If you have a large WordPress setup or a server with limited resources, then you will often see the “504 Gateway Time-out” error.

You can follow the steps given below to increase the timeout value. PHP default is 30s.

Changes in php.ini

If you want to change max execution time limit for php scripts from 30 seconds (default) to 300 seconds.


In Apache, applications running PHP as a module above would have suffice. But in our case we need to make this change at 2 more places.

Changes in PHP-FPM

This is only needed if you have already un-commented request_terminate_timeout parameter before. It is commented by default, and takes value of max_execution_time found in php.ini



Changes in Nginx Config

To increase the time limit for by

If you want to increase time-limit for all-sites on your server, you can edit main nginx.conf file:

Add following in http{..} section

Reload PHP-FPM & Nginx

Don’t forget to do this so that changes you have made will come into effect:

Source :

Menangkal Serangan DDOS Di VPS Dengan Block IP Melalui IP Tables

Masih seperti sebelumnya, artikel ini adalah copas mentah2 dari

Menangkal Serangan DDoS Di VPS

Cara ini sangat sederhana tapi juga ampuh untuk melihat serangan ddos yang menyerang server atau vps anda Big_smile2 ,1. login ke vps menggunakan putty masuk sebagai user root
2. Jalankan Perintah Berikut ini


Perintah di atas akan menampilkan daftar / list IP pengujung dan jumlah koneksi yg di buat tiap IP tsb.

Akan tampil seperti ini misalnya:


Pada tampilan di atas sebelah kiri menujukan Jumlah koneksi dan sebelah kanan IP yg mengakses

3.Perhatikan tampilan tsb dan koneksi standar pada server web biasanya maksimal 20 konneksi per ip per detik, anda bisa melihat apa ada yg melebihi 30 koneksi, misal anda menemukan ada IP yng koneksinya mewlebihi 20, coba anda jalankan perintah tadi minimal 5 kali dalam tempo minimal 5 detik


Jika anda msh melihat IP tsb dengan koneksi yg tidak menurun bahkan bertambah, sudah di pastikan IP tsb bermasalah.

4. Tapi tunggu dulu jangan berpikir negatif Big_smile2 catat IP tsb cek dulu punya siapa IP tsb anda bisa mengecek IP melalui, jika hasilnya ip tsb milik google kemungkinan itu google yg sedang melakukan bot crawling / mengindex server/website anda jika tidak brarti itu IP bahaya , di sini kami hanya merekomendasikan IP google Big Grin

5. Lakukan Block IP agar tidak bisa mengakses server anda dengan cara:


x.x.x.x di ganti IP yg ingin anda block

6. Jika sudah coba anda cek koneksi lagi :


di pastikan juika IP tadi sudah tidak akan tampil karena sudak di block

7. Untuk melihat Status IP yg sudah di block td anda bisa dengan cara :


Maka akan tampil seperti ini misalnya:


Terlihat bahwa IP yg tadi anda block, dan IP tsb terus berusaha mengirim paket lihat bagian Chain INPUT jumlah pkts akan terus bertambah dan nilai byte juga pasti bertambah.

Membuat Firewall di VPS Ubuntu 12.04

Dicopas mentah2 dari 😉

Creating the IP Table:

If you type in the following, you can see the current rules in the virtual server’s IP Table:

They should look like this:

If you have another set of rules in place or want to start fresh, you can always set the rules back to the default by flushing and deleting all of them:

Additionally, if you want speed up your work with IP Table, you can include -n in the command. This option disables DNS lookups and prevents the command from trying to find the reverse of each IP in the ruleset. You could use this to list rules, as an example:

A Basic Firewall

As it stands the current rules allow all connections, both incoming and outgoing. There are no security measures in place whatsoever. As we build up the table, keep in mind that as soon as a packet is ACCEPTED, REJECTED, or DROPPED, no further rules are processed. Therefore the rules that come first take priority over later ones.

While creating the rules, we have to be sure to prevent ourselves from accidentally blocking SSH (the method through which we connected to the server).

To start off, let’s be sure to allow all current connections, all of the connections at the time of making the rule, will stay online:

We can go ahead and break this down:

  1. -A tells the IP table to append a rule to the table.
  2. INPUT designates this rule as part of the Input chain.
  3. m conntrack followed by the –cstate ESTABLISHED,RELATED guarantees that the result of this rule will only apply to current connections and those related to them are allowed
  4. -j ACCEPT tells the packet to JUMP to accept and the connections are still in place.

After we are assured that all the current connections to the virtual private server can stay up uninterrupted, we can proceed to start blocking off other insecure connections.

Let’s assume that we want to block all incoming traffic, except for those coming in on 2 common ports: 22 for SSH and 80 for web traffic. We proceed by allowing all traffic on the designated ports with the following commands:

In both of these commands, the -p option stands for the protocol with which the connection is being made, in this case tcp, while the –dport specifies the port through which the packet is being transmitted.

After we have guaranteed that the desirable traffic will make it through the firewall, we can finish up by blocking all remaing traffic from accessing our virtual server. Because this is the last rule in the list, all traffic that matches any of the previous rules in the IP Table will not be affected, and will be treated as we set up previously.

Let’s make a rule to block all of the remaining traffic:

With that, we can see what our updated rules look like:

We are almost finished. However, we are missing one more rule. We need to provide our VPS with loopback access. If we were to add the rule now without further qualifiers, it would go to the end of the list and, since it would follow the rule to block all traffic, would never be put into effect.

In order to counter this issue, we need to make this rule first in the list, using the INPUT option :

  1. -I INPUT 1 places this rule at the beginning of the table
  2. lo refers to the loopback interface
  3. -j ACCEPT then guarantees that the loopback traffic will be accepted

Now we have finished creating a basic firewall. Your rules should look like this (we can see the details of the iptable by typing -v):

However, as soon as the virtual server reboots, the IP tables will be wiped. The next step will go over saving and restoring the IP tables.

Saving IP Tables

Although the IP tables are effective, they will automatically be deleted if the server reboots. To make sure that they remain in effect, we can use a package called IP-Tables persistent.

We can install it using apt-get:

During the installation, you will be asked if you want to save the iptable rules to both the IPv4 rules and the IPv6 rules. Say yes to both.

Your rules will then be saved in /etc/iptables/rules.v4 and /etc/iptables/rules.v6.

Once the installation is complete, start iptables-persistent running:

After any server reboot, you will see that the rules remain in place.

Optimasi Plugin WP Super Cache di Nginx Web Server

Hello mas brot, lagi2 artikel ini hanyalah kopas mentah2 belaka karena memang ogut sangat tidak pandai bikin artikel, apalagi tutorial xexexexexex….

Bagi yang ga ngerti apa itu web server, nginx, ssh lan konco2ne mending ga usah baca artikel ini, dari pada nanti malah pusing, klemun2, terus mutah :v

Okelah kalo begitu, karena 2 paragraph di atas saya sudah yakin sangat unik sekali karena memang hasil pemikiran sendiri, jadi mari kita masuk ke Kopas 😀

Standard WordPress-Nginx configuration with WP Super cache support:

As you are getting into Nginx, I hope you don’t need my help with configuring WP Super Cache plugin.

Still, make sure you are using “Use mod_rewrite to serve cache files. (Recommended)” option under “Advanced” tab.

Following configuration supports:

  1. Static Page Caching using Disk
  2. Direct browser cache for static content like images, js, css, etc



To simplify configuration, I haven’t added Mobile user agent checks. We are in the iPhone era where finally phones are getting smart. So there is no need to create separate mobile site, when you can cater to today’s iPhone/Android devices using responsive designs.

Don’t Forget:

Always test your Nginx configuration and then reload it. All changes to Nginx config must be followed with these commands:

Important Note:

WP Super Cache caching will conflict with plugins that uses query vars. WooCommerce is an example known plugin known to work with above configuration. Reason is following line: 

It doesn’t passes $args to /index.php. If you set last try_files argument to /index.php?$args as with other WordPress-Nginx configuration, WP Super Cache, itself will break!

if you get error like this “Mod rewrite may not be installed” just install this plugin the remove the error

Artikel ini sepenuhnya diKopas dari –>

Mobile redirect dengan Nginx server

Dicopas sepenuhnya dari  😀

Using Nginx for redirection

Visitors should not have to go to the Rails app just to be redirected away from it. By having the logic in Nginx, we can reduce unnecessary request to the Rails app and also reuse the implementation for other projects that might be built with Node.js, Python, static HTML, or something else.

Defining the flow

The logic that most websites use for desktop / mobile redirection:

  • Mobile devices visiting should redirect to
  • Desktop clients should continue to
  • Mobile devices should be allowed to the desktop website if visiting through
  • A cookie should be set when a mobile device chooses the desktop version to remember the choice.

Redirecting to mobile website

To start, here is a very basic Nginx server configuration that can serve static pages.


The redirection logic is actually quite simple, but one gotcha is that if blocks in Nginx can be unpredictable. There is even an article on the Nginx Wiki about the evils of if.

Because of this, if blocks are kept out of a location context and only used for setting variables, with one exception being the actual redirection.


The $mobile_request variable is initialized as false, then is set to true if the requesting browser is a mobile device. Finally, if the $mobile_request variable is true, a redirect happens.

Setting a cookie, checking a cookie

Cookie creation should be handled in Nginx, too, but I had some initial issues since add_header cannot be inside an if block in the server context (though it can in the location context).

Because of the add_header restriction, the $mobile_cookie variable needs to be initialized before the if block that could set it to false, because add_header Set-Cookie is always going to be used.


Exceptions to the redirection

One major issue that can come up from this implementation is the mobile check happens on every HTTP request through Nginx. This is not a problem for our company website since assets are hosted on Amazon S3, but if your hosting assets at /assets/ or elsewhere, you’ll need to add exceptions to treat all request to that directory or file as non-mobile.


All together

Because of the $request_uri in the redirection block, the code assumes the routes of your desktop website and mobile website will be the same, or at least mapped accordingly on the mobile side of the implementation, but that’s another post.