The Perfect APC Configuration

Here was my setup on an Amazon Medium Instance using APC:

php.ini configuration

[APC]
extension=apc.so
apc.enabled=1
apc.shm_segments=1

;32M per WordPress install
apc.shm_size=128M

;Relative to the number of cached files (you may need to watch your stats for a day or two to find out a good number)
apc.num_files_hint=7000

;Relative to the size of WordPress
apc.user_entries_hint=4096

;The number of seconds a cache entry is allowed to idle in a slot before APC dumps the cache
apc.ttl=7200
apc.user_ttl=7200
apc.gc_ttl=3600

;Setting this to 0 will give you the best performance, as APC will
;not have to check the IO for changes. However, you must clear 
;the APC cache to recompile already cached files. If you are still
;developing, updating your site daily in WP-ADMIN, and running W3TC
;set this to 1
apc.stat=1

;This MUST be 0, WP can have errors otherwise!
apc.include_once_override=0

;Only set to 1 while debugging
apc.enable_cli=0

;Allow 2 seconds after a file is created before it is cached to prevent users from seeing half-written/weird pages
apc.file_update_protection=2

;Leave at 2M or lower. WordPress does't have any file sizes close to 2M
apc.max_file_size=2M

;Ignore files
apc.filters = "/var/www/apc.php"

apc.cache_by_default=1
apc.use_request_time=1
apc.slam_defense=0
apc.mmap_file_mask=/var/www/temp/apc.XXXXXX
apc.stat_ctime=0
apc.canonicalize=1
apc.write_lock=1
apc.report_autofilter=0
apc.rfc1867=0
apc.rfc1867_prefix =upload_
apc.rfc1867_name=APC_UPLOAD_PROGRESS
apc.rfc1867_freq=0
apc.rfc1867_ttl=3600
apc.lazy_classes=0
apc.lazy_functions=0

While this configuration works great for me, it may not for you. Finding “The Perfect APC Configuration” is like asking how many stars are in the sky. The are endless variables, like, “How much RAM, how many websites, do your websites support lazy classes, etc…” The best way to create your config is to do a little research. This post was meant to give you a push in the right direction.

P.S. There seems to be a lot of debate about apc.stat = 0. The general thought is, set apc.stat=0 on production servers and it will prevent APC from actually going to the IO to check if the file has been changed. However, the WordPress dashboard and W3TC get kinda bitchy with this setting!

My advice: Are working in the WordPress dashboard daily, and running W3TC? Then set: apc.stat = 1. Your fragmentation will be higher. Your sites will loadslightly slower, but when you click Update Post, APC will flush that piece of cache.

Source:  Greg Rickaby

Desvio Condicional em Shell Script

Para efetuar teste condicionais, o shell script possui operadores de verificação como (maior/menor/menor que/igual/ etc …) veja abaixo os exemplos :

if [ condição ]; then
    comando...1
    comando...2
    comando...N
fi

-eq igual

-ne diferente

-gt maior

-ge maior ou igual

-lt menor

-le menor ou igual

-d se é um diretório

-e se existe

-z se é vazio

-f se contem texto.

-r se o arquivo possui permissão de leitura

-w se o arquivo possui permissão de escrita.

-x se o arquivo é executável.

Fonte: http://www.nacaolivre.com.br/shell-script/desvio-condicional-em-shell-script/

Unix - Special Variables

Previous tutorial warned about using certain nonalphanumeric characters in your variable names. This is because those characters are used in the names of special Unix variables. These variables are reserved for specific functions.

For example, the $ character represents the process ID number, or PID, of the current shell:

$echo $$

Above command would write PID of the current shell:

29949

The following table shows a number of special variables that you can use in your shell scripts:

Variable	Description
$0	The filename of the current script.
$n	These variables correspond to the arguments with which a script was invoked. Here n is a positive decimal number corresponding to the position of an argument (the first argument is $1, the second argument is $2, and so on).
$#	The number of arguments supplied to a script.
$*	All the arguments are double quoted. If a script receives two arguments, $* is equivalent to $1 $2.
$@	All the arguments are individually double quoted. If a script receives two arguments, $@ is equivalent to $1 $2.
$?	The exit status of the last command executed.
$$	The process number of the current shell. For shell scripts, this is the process ID under which they are executing.
$!	The process number of the last background command.

Command-Line Arguments:

The command-line arguments $1, $2, $3,...$9 are positional parameters, with $0 pointing to the actual command, program, shell script, or function and $1, $2, $3, ...$9 as the arguments to the command.

Following script uses various special variables related to command line:

#!/bin/sh

echo "File Name: $0"
echo "First Parameter : $1"
echo "First Parameter : $2"
echo "Quoted Values: $@"
echo "Quoted Values: $*"
echo "Total Number of Parameters : $#"

Here is a sample run for the above script:

$./test.sh Zara Ali
File Name : ./test.sh
First Parameter : Zara
Second Parameter : Ali
Quoted Values: Zara Ali
Quoted Values: Zara Ali
Total Number of Parameters : 2

Special Parameters $* and $@:

There are special parameters that allow accessing all of the command-line arguments at once. $* and $@ both will act the same unless they are enclosed in double quotes, "".

Both the parameter specifies all command-line arguments but the "$*" special parameter takes the entire list as one argument with spaces between and the "$@" special parameter takes the entire list and separates it into separate arguments.

We can write the shell script shown below to process an unknown number of command-line arguments with either the $* or $@ special parameters:

#!/bin/sh

for TOKEN in $*
do
   echo $TOKEN
done

There is one sample run for the above script:

$./test.sh Zara Ali 10 Years Old
Zara
Ali
10
Years
Old

Note: Here do...done is a kind of loop which we would cover in subsequent tutorial.

Exit Status:

The $? variable represents the exit status of the previous command.

Exit status is a numerical value returned by every command upon its completion. As a rule, most commands return an exit status of 0 if they were successful, and 1 if they were unsuccessful.

Some commands return additional exit statuses for particular reasons. For example, some commands differentiate between kinds of errors and will return various exit values depending on the specific type of failure.

Following is the example of successful command:

$./test.sh Zara Ali
File Name : ./test.sh
First Parameter : Zara
Second Parameter : Ali
Quoted Values: Zara Ali
Quoted Values: Zara Ali
Total Number of Parameters : 2
$echo $?
0
$

Fonte: tutorialspoint

MTU woes in IPsec tunnels and how you can fix it

Today I ran into a problem with IPsec Xauth PSK and the built-in Android VPN client (Android 4.1.2), resulting in some sites (such as www.yahoo.com) not loading through the VPN tunnel. Turns out I was dealing with MTU issues. When the Android VPN is started, it sets the MTU to 1500 on the tun0 interface:

$ ip link show tun0
33: tun0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 500 link/none

Looking at the Android Source, it appears someone must have forgotten to take care of IPsec Xauth PSK. With PPTP and L2TP based VPNs, the MTU is reduced to 1400 (line 758 – 778).

In comparison:

• strongSwan Android client: MTU 1400
• OS X / iOS 7 built-in IPsec client: MTU 1280 (for what it’s worth, 1280 is also the minimum IPv6 packet size and thus the MTU minimum required to make IPv6 work)
• Windows 7 built-in IPsec client: MTU 1400
• Cisco VPN client: MTU 1300

Among the tested clients, only the connection through the Android VPN client was causing the issue with stalling websites. In a nutshell, I was able to fix it with the following on the VPN server:

$ iptables -t mangle -A FORWARD -o eth0 \
 -p tcp -m tcp --tcp-flags SYN,RST SYN \
 -m tcpmss --mss 1361:1536 \
 -j TCPMSS --set-mss 1360

$ echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc

And here is why.

IP fragmentation – The original problem.

On the VPN server side, we have the interface set to a standard Ethernet MTU 1500. In the scenario with the Android client, the MTU along the entire path is 1500. This leaves room for up to 1460 bytes of data payload per packet (also referred to as the maximum segment size MSS).

Keep in mind that IPsec in tunnel mode adds an ESP header and an additional IP header for tunneling the packet (usually with an additional size of around 70-80 bytes). When a packet is nearly the size of the MTU and when you tack on this encapsulation overhead, it is likely to exceed the MTU of the outbound link.  That’s where IP fragmentation kicks in – which could lead to performance degradation of your VPN tunnel. Or worse…

Path MTU discovery (PMTUD). A failed solution.

To avoid IP fragmentation, many TCP/IP stacks have path MTU discovery (PMTUD) implemented. To tell you right away: It doesn’t work for me, and it’s not going to work for you either. PMTUD attempts to discover the largest IP datagram that may be sent without fragmentation through an IP path. Instead of fragmenting a too-large IP packet, the VPN server is told (through theDon’t Fragment (DF) flag in the IP header of the sender) to discard the packet and reply with an ICMP fragmentation required (type3, subtype 4) message.

Recap: The sender is the website that you try to load on your VPN client.

When the sender receives this ICMP packet, it learns to use a smaller MTU for packets sent to our VPN server. In theory. In reality, many websites (senders like www.yahoo.com) stupidly implement ICMP filters that break PMTUD functionality. And that’s where hell breaks loose.  The sender is expecting an acknowledgement for the original packet from our server, but since the packet was discarded, the acknowledgment never comes. Time goes by, then the sender repeats sending the too-large packet. The result? The VPN sender discards the packet, again, sends yet another ICMP message, and so on. Meanwhile our client on the other end of the VPN tunnel cannot tell what’s happening and is desperately waiting for some data. Everything appears to be stalled – a state which is also referred to as a black hole connection.

Because PMTUD doesn’t always work on the Internet, the use of it only makes sense in a site-to-site VPN, where basically one operator maintains the networks and is able to enable the forwarding of the “fragmentation required” ICMP (type 3, subtype 4) notifications in all firewalls in between.

MSS size reduction. A working solution.

So we can rule out PMTUD, but there is another way to assure that our VPN connection is working properly.

$ iptables -t mangle -A FORWARD -o eth0 \
 -p tcp -m tcp --tcp-flags SYN,RST SYN \
 -m tcpmss --mss 1361:1536 \
 -j TCPMSS --set-mss 1360

This iptables rule reduces the size of the allowed packet size by reducing the MSS of TCP SYN packets. The –set-mss value explicitly sets the MSS to 1360, which is a customary size for IPsec IPv4 interfaces. The –mss option is used to match only those MSS that are between 1361 and 1536 bytes (we don’t want to rewrite the MSS of a VPN client that uses a smaller MSS). The result in a tcpdump:

05:01:56.795798 IP 172.16.16.1.38695 > r2.ycpi.vip.ac4.yahoo.net.http: Flags [S], seq 2621580326, win 14600, options [mss 1460,sackOK,TS val 56614 ecr 0,nop,wscale 6], length 0
05:01:56.795865 IP vpn.zeitgeist.se.38695 > r2.ycpi.vip.ac4.yahoo.net.http: Flags [S], seq 2621580326, win 14600, options [mss 1360,sackOK,TS val 56614 ecr 0,nop,wscale 6], length 0
05:01:56.802695 IP r2.ycpi.vip.ac4.yahoo.net.http > vpn.zeitgeit.se.38695: Flags [S.], seq 3057551576, ack 2621580327, win 14480, options [mss 1460,sackOK,TS val 1410945796 ecr 56614,nop,wscale 8], length 0

In line 1, you see the request from our Android client through the tunnel to yahoo.com. Notice the MSS is 1460. In the second line, it is our VPN host initiating the TCP handshake with the external site. Only now  the MSS value is rewritten to 1360, thanks to our iptables rule. As a consequence, the TCP connection will use the lower MSS of the two end points, which is 1360. Voila!

You can go further and restrict the iptables rule to rewrite only those packets that are forwarded from our VPN client:

$ iptables -t mangle -A FORWARD -o eth0 \
 -p tcp -m tcp --tcp-flags SYN,RST SYN \
 -s 172.16.16.0/24 \
 -m tcpmss --mss 1361:1536 \
 -j TCPMSS --set-mss 1360

This assumes that the address pool of your virtual IPs is 172.16.16.0/24 (see rightsourceip in /etc/ipsec.conf).

There is also an option to determine the MSS size dynamically (“MSS clamping”, via the –clamp-mss-to-pmtu option), but it wouldn’t fix IPsec for clients that set their MTU too high (like in the Android example).

The MSS iptables rule doesn’t work with UDP applications. UDP is a connectionless protocol; hence there is no way to negotiate a MSS during the handshake. The only solution to guarantee that UDP works is to disable the Don’t Fragment (DF) bit in the IP header of the sender. This will allow our VPN server to fragment any UDP packet, if necessary. In Linux, you do it like this:

$ echo 1 >/proc/sys/net/ipv4/ip_no_pmtu_disc

The VPN server will fragment outgoing UDP packets that exceed the interface MTU, which may not be as great for performance and reliability reasons, but at least it doesn’t break the tunnel connection. Fortunately, most folks don’t use UDP for anything much greater than DNS.

Fonte: zeitgeist.se

INSTALANDO E CONFIGURANDO O VSFTPD – CENTOS

O VSFTP é um servidor de FTP muito fácil de configurar.

Começamos instalando ele.

# Na sua Shell rode:

yum install vsftpd -y

# Depois disto vamos no diretório dele para modificarmos o arquivo de configuração.

cd /etc/vsftpd

mv vsftpd.conf vsftpd.conf.BACKUP

vim vsftpd.conf

anonymous_enable=NO
local_enable=YES
write_enable=YES
local_umask=022
dirmessage_enable=YES
xferlog_enable=YES
connect_from_port_20=YES
xferlog_std_format=YES
ftpd_banner=Bem-Vindo ao FTP.
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list
listen=YES
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
xferlog_file=/var/log/vsftpd.log
pasv_enable=YES
pasv_min_port=12000
pasv_max_port=12100

# Note que no arquivo a cima, temos todos os parâmetros necessários para que o VSFTP funcione.

# Não esqueça de modificar as linhas: “ftpd_banner=Bem-Vindo ao FTP.” “chroot_list_file=/etc/vsftpd/chroot_list” “xferlog_file=/var/log/vsftpd.log”  conforme sua necessidade.

ftpd_banner=Bem-Vindo ao FTP. = Mensagem que será mostrada ao usuário quando ele se conectar no servidor.

chroot_list_file=/etc/vsftpd/chroot_list = Caminho do arquivo que contém os usuários liberados para acessar o FTP

xferlog_file=/var/log/vsftpd.log = Caminho do LOG do VSFTP

# Depois das modificações, basta Iniciarmos o VSFTP, criar o arquivo chroot_list e incluir o usuário no mesmo e criar o usuário FTP.

/etc/init.d/vsftpd start

touch /etc/vsftpd/chroot_list

adduser teste

vim /etc/vsftpd/chroot_list ( inclua aqui a linha “teste”, para informarmos ao VSFTP que o usuário será o teste )

Agora, você já tem um servidor FTP rodando.

Fonte: psyscrew