Apache server-status

To the uninitiated, the mod_status output can look like so much gobbledegook, but it’s really quite straightforward. Let’s take a look at some sample output.

5973f0b229ec02_

The first few lines identify and provide a brief description of your server. The server version information includes an incomplete list of some of the modules compiled into your server. Our example server is running on a Unix system and has been compiled with support for the PHP scripting language. (The level of detail provided by the server version line may be limited by the ServerTokens configuration directive.)
5973f0b229ec03_

The next block represents the server’s current state. Our example server has only been up for a few minutes and hasn’t yet seen much activity. It is currently dealing with three requests, one of which is my request for the server status itself. The message that five servers are idle servers is a clue that this server is configured to maintain a pool of at least five spare child processes ready to spring into action should the need arise.
5973f0b229ec04_

No, that’s not boring morse-code; it’s the “scoreboard,” a pseudo-graphical representation of the state of the server’s child processes. According to the included Scoreboard Key, our server is replying to one request, maintaining two KeepAlive connections, and is maintaining five idle processes. A busier server’s scoreboard would look more like:
5973f0b229ec05_

For more on pool regulation and KeepAlive, see my earlier HTTP Wrangler column, “An Amble Through Apache Configuration.”
5973f0b229ec06_

In addition to a more general overview of your server’s activity, Apache Server Status for somedomain.com Server Version: Apache/1.3.9 (Unix) PHP/4.0b3 Server Built: Mar 4 2000 17:01:01 gets down to the nitty-gritty, displaying a snapshot of the individual requests it is currently handling. Let’s take a gander at a fairly representative request. Please note that the output above has been split in half for display purposes.

Current Time: Thursday, 13-Apr-2000 17:22:36 PDT Restart Time: Thursday, 13-Apr-2000 17:15:26 PDT Parent Server Generation: 14 Server uptime: 7 minutes 10 seconds Total accesses: 42 - Total Traffic: 187 kB CPU Usage: u.1 s.1 cu0 cs0 - .0465% CPU load .0977 requests/sec - 445 B/second - 4559 B/request 3 requests currently being processed, 5 idle servers Srv
The ID of the child process and its generation. The generation increases each time a child process is restarted, whether due to a server-restart or a limit placed on the number of processes a child is allowed to handle. See the MaxRequestsPerChild directive.
K___K_W_........................................................ ................................................................ ................................................................ ................................................................ Scoreboard Key: "_" Waiting for Connection, "S" Starting up, "R" Reading Request, "W" Sending Reply, "K" KeepAlive (read), "D" DNS Lookup, "L" Logging, "G" Gracefully finishing, "." Open slot with no current process PID
The child’s process ID.
WWKW__WW_KKKWK__KKKKWKKKKK_WKKK_KK__KRWKKK__KK___K____WKK__KWWKK _K___K___WWKWWW_W_W_WWWK_WW_WWWLWWW_KWWKKWKWWKWWKKWW_KWKKKKW__WK WKWWW_KKWKKKWK_KW_KKKK__KK_KKKWWK_KW__K_KKK_K..........W........ ................................................................ Acc
The first number in this trio is the number of accesses or requests using this connection. For non-KeepAlive connections, this will be 0 since each request makes its own connection and so is always the first (and last). The second is the number of requests handled thus far by this child. The third is the number of requests handled by this slot; the child may have come and gone, its slot taken by another.
Srv PID Acc M CPU SS Req Conn Child Slot 0-14 29987 0/24/24 W 0.09 2 0 0.0 0.16 0.16 Client VHost Request Request 127.0.0.1 www.mydomain.net GET /server-status HTTP/1.0 Mode
The child’s mode of operation; one of the following possibilities:
5973f0b229ec012_
mod_status CPU SS Req Conn Child Slot
Some of the less useful bits and pieces…

CPU: The child’s CPU usage in number of seconds.
SS: Seconds elapsed since the beginning of the request.
Req: Milliseconds taken to process the request.
Conn: Kilobytes transferred across this connection.
Child: Megabytes transferred by this child process.
Slot: Megabytes transferred by this slot, across children.

0-14 VHost
Perhaps your server hosts multiple virtual domains; how would you determine which page is being requested by 29987?. The VHost column helps you sort out which request is coming to which virtual host — in this example, www.mydomain.net.
0/24/24 Request
This particular hit is my request for server-status. The W bit indicates a simple request for a document (as opposed to sending data to the server using POST). The browser (in this case the Unix command-line "_" Waiting for Connection, "S" Starting up, "R" Reading Request, "W" Sending Reply, "K" KeepAlive (read), "D" DNS Lookup, "L" Logging, "G" Gracefully finishing, "." Open slot with no current process program) is using 0.09 2 0 0.0 0.16 0.16 version www.mydomain.net.

For more on HTTP, see my earlier HTTP Wrangler column, “Introducing Apache.”

Installation

So how do you install and configure GET /index.html? I make the assumption here that you built and installed Apache from source. If you’re not familiar with building Apache, may I suggest you read my earlier HTTP Wrangler column, Getting, Installing, and Running Apache.

First, move into your Apache source directory.

5973f0b229ec022_

Thankfully Apache’s GET /server-status HTTP/1.0 script creates a cache file, GET, saving us the bother of completely reconfiguring our Apache build from scratch. All we need to do is run wget, supplying the one argument necessary to add HTTP.

If you’ve not already done so, now would be the time to become 1.0.

5973f0b229ec028_

Note: Apache’s mod_status script automagically updates % cd /usr/local/src/apache_1.3.x to include configure; next time you configure you will not need to enable config.status again.

Now that we’ve reconfigured Apache, let’s rebuild.

5973f0b229ec033_

Your screen should look something like:
5973f0b229ec034_

Finally, you’re ready to install your newly freshly built Apache.
5973f0b229ec035_

(While not strictly necessary — reinstalling should only overwrite files that probably haven’t changed since your last install — I always advise backing up your Apache directory.)

Configuration

config.status is easy to configure; in fact the directives already exist in your mod_status file and simply need to be uncommented and edited slightly. If you’re not familiar with Apache configuration, may I suggest you read my earlier HTTP Wrangler column, An Amble Through Apache Configuration.

5973f0b229ec038_

(or wherever your Apache installation’s configuration files are located)

Open your root file in the text editor of your choice and search for the following set of configuration directives:

5973f0b229ec040_

Uncomment everything from # ./config.status --enable-module=status Configuring for Apache, Version 1.3.11 ... Creating Makefile Creating Configuration.apaci in src Creating Makefile in src + configured for Linux platform + setting C compiler to gcc + setting C pre-processor to gcc -E + checking for system header files + adding selected modules + checking sizeof various data types + doing sanity check on compiler and options ... Creating Makefile in src/modules/standard to configure by removing the config.status characters from the beginning of each line.

It’s wise to protect your server-status output from prying eyes. The easiest way to do this is to restrict its access to one computer or domain. Change the mod_status to the name of a computer or domain you wish to allow a peek at server-status. For example, if you’re the webmaven for your server, you may want to allow only your computer,mod_status access, your server-status configuration would look something like:

5973f0b229ec046_

Only one tiny piece left. The default status display isn’t as detailed as what you I showed you above. The more abbreviated version looks something like:
5973f0b229ec047_

In order to see all the gory details, you need to enable “full” status. Find the following lines and uncomment (remove the initial # make) the # make ===> src make[1]: Entering directory `src/httpd/apache_1.3.11' make[2]: Entering directory `src/httpd/apache_1.3.11/src' ===> src/regex ... [several unsightly lines later] ... gcc -DLINUX=2 -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED `../apaci` -o ab -L../os/unix -L../ap ab.o -lap -los -lm -lcrypt make[2]: Leaving directory `src/httpd/apache_1.3.11/src/support' <=== src/support make[1]: Leaving directory `src/httpd/apache_1.3.11' <=== src # directive; the result should look like:
5973f0b229ec050_

That’s all there is to # make install configuration. Save your Mod_status file, shut down and start Apache.
5973f0b229ec053_

Fire up your Web browser on a machine allowed access to your server’s server-status and point it at the URL:
5973f0b229ec054_

Happy reading! For more information on httpd.conf and other aspects of Apache we touched on along the way, visit the Resources section below.

Troubleshooting High I/O Wait in Linux

Linux has many tools available for troubleshooting some are easy to use, some are more advanced.

I/O Wait is an issue that requires use of some of the more advanced tools as well as an advanced usage of some of the basic tools. The reason I/O Wait is difficult to troubleshoot is due to the fact that by default there are plenty of tools to tell you that your system is I/O bound, but not as many that can narrow the problem to a specific process or processes.

Answering whether or not I/O is causing system slowness

To identify whether I/O is causing system slowness you can use several commands but the easiest is the unix command top.

5973f0b22e4162_

From the CPU(s) line you can see the current percentage of CPU in I/O Wait; The higher the number the more cpu resources are waiting for I/O access.
5973f0b22e4163_

Finding which disk is being written to

The above top command shows I/O Wait from the system as a whole but it does not tell you what disk is being affected; for this we will use the  # top top - 14:31:20 up 35 min, 4 users, load average: 2.25, 1.74, 1.68 Tasks: 71 total, 1 running, 70 sleeping, 0 stopped, 0 zombie Cpu(s): 2.3%us, 1.7%sy, 0.0%ni, 0.0%id, 96.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 245440k total, 241004k used, 4436k free, 496k buffers Swap: 409596k total, 5436k used, 404160k free, 182812k cached  command.

5973f0b22e4165_

The iostat command in the example will print a report every 2 seconds for 5 intervals; the wa -- iowait Amount of time the CPU has been waiting for I/O to complete.  tells iostat to print out an extended report.

The 1st report from iostat will print statistics based on the last time the system was booted; for this reason in most circumstances the first report from iostat should be ignored. Every sub-sequential report printed will be based on the time since the previous interval. For example in our command we will print a report 5 times, the 2nd report are disk statistics gathered since the 1st run of the report, the 3rd is based from the 2nd and so on.

In the above example the %utilized for sda is 111.41% this is a good indicator that our problem lies with processes writing to sda. While the test system in my example only has 1 disk this type of information is extremely helpful when the server has multiple disks as this can narrow down the search for which process is utilizing I/O.

Aside from %utilized there is a wealth of information in the output of iostat; items such as read and write requests per millisecond(rrqm/s & wrqm/s), reads and writes per second (r/s & w/s) and plenty more. In our example our program seems to be read and write heavy this information will be helpful when trying to identify the offending process.

Finding the processes that are causing high I/O

iotop

5973f0b22e4167_

The simplest method of finding which process is utilizing storage the most is to use the command iotop. After looking at the statistics it is easy to identify bonnie++ as the process causing the most I/O utilization on this machine.

While iotop is a great command and easy to use, it is not installed on all (or the main) Linux distributions by default; and I personally prefer not to rely on commands that are not installed by default. A systems administrator may find themselves on a system where they simply cannot install the non-defualt packages until a scheduled time which may be far too late depending on the issue.

If iotop is not available the below steps will also allow you to narrow down the offending process/processes.

Process list “state”

The ps command has statistics for memory and cpu but it does not have a statistic for disk I/O. While it may not have a statistic for I/O it does show the processes state which can be used to indicate whether or not a process is waiting for I/O.

The ps state field provides the processes current state; below is a list of states from the man page.

5973f0b22e4168_

Processes that are waiting for I/O are commonly in an “uninterruptible sleep” state or “D”; given this information we can simply find the processes that are constantly in a wait state.

Example:

5973f0b22e4169_

The above for loop will print the processes in a “D” state every 5 seconds for 10 intervals.

From the output above the bonnie++ process with a pid of 16528 is waiting for I/O more often than any other process. At this point the bonnie++ seems likely to be causing the I/O Wait, but just because the process is in an uninterruptible sleep state does not necessarily prove that it is the cause of I/O wait.

To help confirm our suspicions we can use the iostat file system. Within each processes directory there is a file called “io” which holds the same I/O statistics that iotop is utilizing.

5973f0b22e41611_

The  $ iostat -x 2 5 avg-cpu: %user %nice %system %iowait %steal %idle 3.66 0.00 47.64 48.69 0.00 0.00 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sda 44.50 39.27 117.28 29.32 11220.94 13126.70 332.17 65.77 462.79 9.80 2274.71 7.60 111.41 dm-0 0.00 0.00 83.25 9.95 10515.18 4295.29 317.84 57.01 648.54 16.73 5935.79 11.48 107.02 dm-1 0.00 0.00 57.07 40.84 228.27 163.35 8.00 93.84 979.61 13.94 2329.08 10.93 107.02  and -x are the number of bytes that this specific process has written and read from the storage layer. In this case the bonnie++ process has read 46 MB and written 524 MB to disk. While for some processes this may not be a lot, in our example this is enough write and reads to cause the high i/o wait that this system is seeing.

Finding what files are being written too heavily

The lsof command will show you all of the files open by a specific process or all processes depending on the options provided. From this list one can make an educated guess as to what files are likely being written to often based on the size of the file and the amounts present in the “io” file within /proc.

To narrow down the output we will use the  # iotop Total DISK READ: 8.00 M/s | Total DISK WRITE: 20.36 M/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 15758 be/4 root 7.99 M/s 8.01 M/s 0.00 % 61.97 % bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp  options to print only files open by the specific process id.

5973f0b22e41615_

To even further confirm that these files are being written to the heavily we can see if the /tmp filesystem is part of sda.
5973f0b22e41616_

From the output of df we can determine that /tmp is part of the root logical volume in the workstation volume group.
5973f0b22e41617_

Using PROCESS STATE CODES D uninterruptible sleep (usually IO) R running or runnable (on run queue) S interruptible sleep (waiting for an event to complete) T stopped, either by a job control signal or because it is being traced. W paging (not valid since the 2.6.xx kernel) X dead (should never be seen) Z defunct ("zombie") process, terminated but not reaped by its parent.  we can see that the  # for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep "^D"; echo "----"; sleep 5; done D 248 [jbd2/dm-0-8] D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp ---- D 22 [kswapd0] D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp ---- D 22 [kswapd0] D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp ---- D 22 [kswapd0] D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp ---- D 16528 bonnie++ -n 0 -u 0 -r 239 -s 478 -f -b -d /tmp ----  partition part of the sda disk is the partition that the workstation volume group is using and in turn is where /proc exists. Given this information it is safe to say that the large files listed in the  # cat /proc/16528/io rchar: 48752567 wchar: 549961789 syscr: 5967 syscw: 67138 read_bytes: 49020928 write_bytes: 549961728 cancelled_write_bytes: 0  above are likely the files being read & written to frequently.

Deframmenta per ottimizzare le tabelle di MySQL

In MySQL, quando si eliminano record da una tabella, lo spazio è riassegnato automaticamente. E ‘come uno spazio vuoto e formando gli allegati nuovi vantaggio.

Il problema è che se una tabella di eseguire molte operazioni di DELETE, lo spazio fisico del tavolo sarà sempre più frammentato e il rendimento è ridotto.

Nel MyISAM InnoDBOPTIMIZE TABLE comando disponibile ad effettuare l’ottimizzazione su qualsiasi tabella che, tra l’altro, esegue una deframmentazione automatica del tavolo.

Si consiglia vivamente di utilizzare questo comando regolarmente in particolare su tabelle che sono più le dichiarazioni di smaltimento dei record.

Per precauzione, di tenere presente che durante l’esecuzione, naturalmente, la tabella è bloccato. Si deve ricordare quando si sta per l’utilizzo con tabelle di grandi dimensioni e occupato.

La sintassi è la seguente:

OPTIMIZE [NO_WRITE_TO_BINLOG | LOCAL] TABLE mi_tabla1 [, mi_tabla2] ...;

Per fare un tavolo di ottimizzazione frammentati possono essere selezionati per avere spazio libero, probabilmente a causa di DELETE:
SELECT TABLE_SCHEMA,TABLE_NAME
FROM TABLES WHERE TABLE_SCHEMA NOT IN ("information_schema","mysql") AND
Data_free > 0

Un semplice script per deframmentare in automatico : 
#!/bin/bash

# Get a list of all fragmented tables
FRAGMENTED_TABLES="$( mysql -e 'use information_schema; SELECT TABLE_SCHEMA,TABLE_NAME \
FROM TABLES WHERE TABLE_SCHEMA NOT IN ("information_schema","mysql") AND \
Data_free > 0' | grep -v "^+" | sed "s,\t,.," )"

for fragment in $FRAGMENTED_TABLES; do
   database="$( echo $fragment | cut -d. -f1 )"
   table="$( echo $fragment | cut -d. -f2 )"
   [ $fragment != "TABLE_SCHEMA.TABLE_NAME" ] && mysql -e "USE $database;\
   OPTIMIZE TABLE $table;" > /dev/null 2>&1
done

Mysqldump per prendere solo lo schema di una tabella

Citazione

Mysqldump è uno strumento che viene utilizzato per creare copie di backup (o dump) dei database, incusi dati struttura e schemi. Ci sono una serie di switch (flags) da riga di comando che si possono lanciare per scaricare solo i dati o solo la struttura invece di tutto.

Dump della struttura del database per tutte le tabelle senza dati

Aggiungere il flag -d per indicare che nessun dato deve essere incluso nell’output.

Il seguente comando dump della struttura della tabella per tutte le tabelle nel database specificato MySQL:

mysqldump -d -u -p someuser miodatabase

Il flag-d dice di non inserire i dati nel dump. In alternativa si può usare –no-data che è più semplice da ricordare.
mysqldump --no-data -u  -p someuser miodatabase

Dump della struttura del database per una sola tabella senza dati

Esempio per una tabella

mysqldump-d-u-p someuser miodatabase prodotti

Pratiche di dumping la struttura del database per la tabella con i diversi dati

Questa è la stessa per un tavolo, ma solo specificare tabelle aggiuntive come molti dopo il nome del database come vorreste discarica. Questo comando eseguirà il dump della struttura per i “prodotti” tavoli “categorie” e “utenti”:

mysqldump-d-u-p someuser prodotti miodatabase categorie di utenti

Pratiche di dumping la struttura in un file

Tutti i comandi di esempio sopra scrivere il dump sullo standard output, nel senso che ti scorrere verso l’alto il terminale / finestra prompt dei comandi che non può essere molto utile. Per salvare in un file invece reindirizzare l’output. Per esempio:

mysqldump-d-u-p someuser miodatabase> mydatabase.sql

È possibile utilizzare il contenuto di questo file con il tool comando “mysql” linea per creare tali tabelle stesse in un altro database:
mysql-u-p someuser anotherdatabase 

Creazione instanza mysql parallela

Citazione

… ovvero come faccio ad avere due instanze indipendenti di mysql sullo stesso server ?

Attenzione :

Questo how-to è stato scritto e pensato per Ubuntu/Debian in particolare, alcuni path e directory potrebbero essere differenti nella vostra versione di Linux

1. Creo directory e predispongo i file di log

mkdir /var/lib/mysql2
chown −R mysql.mysql /var/lib/mysql2/
mkdir /var/log/mysql2
chown −R mysql.mysql /var/log/mysql2

2. Creo una nuova configurazione di mysql

cp -R /etc/mysql/ /etc/mysql2

A questo punto dobbiamo modificare il file di configurazione di mysql e cambiare la porta, socket e pid : 
cd /etc/mysql2/
sed −i 's/3306/3307/g' my.cnf
sed −i 's/mysqld.sock/mysqld2.sock/g' my.cnf
sed −i 's/mysqld.pid/mysqld2.pid/g' my.cnf
sed −i 's/var\/lib\/mysql/var\/lib\/mysql2/g' my.cnf
sed −i 's/var\/log\/mysql/var\/log\/mysql2/g' my.cnf

3. Inizializzazione e start

Abbiamo a questo punto dell’how-to due scelte da fare :

1. creiamo una instanza vuota con database di default come se fosse una nuova installazione 

2. Copiamo i database da un’altra instanza 

Nel caso :

1.  mysql_install_db −−user=mysql −−datadir=/var/lib/mysql2/
2. cp −R /var/lib/mysql/* /var/lib/mysql2/*

Possiamo a questo punto far partire l’instanza :
mysqld_safe --defaults-file=/etc/mysql2/my.cnf &

e connetterci in due modi :
mysql -S /var/run/mysqld/mysqld2.sock

o
mysql -h 127.0.0.1 -P 3307

Possiamo a questo punto creare uno script di init (es: mysql2) in /etc/init.d/

 Bash | 
 
 copy code |
?

01
#!/bin/sh
02
# Begin /etc/init.d/mysql
03
 
04
#source /etc/init.d/functions
05
 
06
case "$1" in
07
        start)
08
                echo -n "Starting mysql..."
09
                /usr/bin/mysqld_safe --defaults-file=/etc/mysql2/my.cnf >/dev/null 2>&1  &
10
                ret=$?
11
                ;;
12
 
13
        stop)
14
                echo -n "Stopping mysqld..."
15
#               kill `cat /var/run/mysqld/mysqld-rep.pid`
16
                mysqladmin -S /var/run/mysqld/mysqld2.sock shutdown > /dev/null 2>&1
17
                ret=$?
18
                ;;
19
 
20
        restart)
21
                $0 stop
22
                /usr/bin/sleep 1
23
                $0 start
24
                ;;
25
 
26
        status)
27
                statusproc /usr/bin/mysqld
28
                ;;
29
 
30
        *)
31
                echo "Usage: $0 {start|stop|restart|status}"
32
                exit 1
33
        ;;
34
 
35
esac
36
 
37
exit $?
38

se voglio farlo partire al boot :

update-rc.d mysql2 defaults

Protezione [base] contro DOS

mod_evasive è un altro modulo di Apache in grado di aumentare la sicurezza del sistema proteggendoci da attacchi DOS e D-DOS sulla porta 80.
Gli attacchi di tipo DOS e D-DOS (Denial of Services e Distributed Denial of Services) sono attacchi atti a rendere inaccessibili i sistemi a causa di un intenso traffico dati. Grazie a questo modulo, però, riusciamo a prevenire questo tipo di attacco quando viene rivolto ad Apache in quanto il modulo tiene traccia del numero di connessioni provenienti da un determinato IP e, in caso di superamento della soglia, interviene bloccandole.
Per installare il modulo su Debian/Ubuntu è sufficiente lanciare il comando:

apt-get install libapache2-mod-evasive

Quindi creiamo la directory per i log:
mkdir -p /var/log/apache2/evasive
chown -R www-data:root /var/log/apache2/evasive

Ora creiamo un file di configurazione per il modulo:
/etc/apache2/conf.d/modevasive.conf
<IfModule mod_evasive20.c>
DOSHashTableSize 3097
DOSPageCount 5
DOSSiteCount 100
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 600
DOSLogDir "/var/log/apache2/evasive"
</IfModule>

e riavviamo Apache:
/etc/init.d/apache2 restart

Per collaudare il funzionalmento del modulo, c’è un semplice script perl incluso con la documentazione:
# perl /usr/share/doc/libapache2-mod-evasive/examples/test.pl 
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 200 OK
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden
HTTP/1.1 403 Forbidden

List tutti i vhost di apache

Ecco uno script perl/bash dove tiro fuori formattati bene tutti i vhost di apache :

Modo più verboso :

 Bash | 
 
 copy code |
?

1
/usr/sbin/apache2ctl&nbsp;&minus;S&nbsp;2>&1&nbsp;|&nbsp;perl&nbsp;&minus;ne&nbsp;'m@.*port\s+([0&minus;9]+)\s+\w+\s+(\S+)\s+\((.+):.*@&nbsp;&&&nbsp;do&nbsp;{&nbsp;print&nbsp;"$2:$1\n\t$3\n";&nbsp;$root&nbsp;=&nbsp;qx{grep&nbsp;DocumentRoot&nbsp;$3};&nbsp;$root&nbsp;=~&nbsp;s/^\s+//;&nbsp;print&nbsp;"\t$root\n"&nbsp;};'

Modo meno verboso :

 Bash | 
 
 copy code |
?

1
#!/bin/bash
2
apache2ctl&nbsp;&minus;S&nbsp;2>&1&nbsp;|&nbsp;grep&nbsp;&minus;v&nbsp;Syntax&nbsp;|&nbsp;perl&nbsp;&minus;ne&nbsp;'m@.*port\s+([0&minus;9]+)\s+\w+\s+(\S+)\s+\((.+):.*@&nbsp;&&&nbsp;do&nbsp;{&nbsp;print&nbsp;"$2:$1\n";};'

Mysql Proxy

Vi è mai capitato di dover configurare un’applicazione in modo che in un’archiettura mysql master/slave scriva automaticamente sul master e legga dagli slave senza modificare l’applicativo ?

Mysql-proxy è quello che fa per te !

MySQL Proxy è un programma che si interpone fra un client e un server MySQL, per consentire di effettuare operazioni sul traffico di dati, in maniera trasparente per l’utente. MySQL Proxy usa il protocollo client/server esteso di MySQL, introdotto con la versione 4.1. Pertanto, questa applicazione è compatibile con i server dalla versione 4.1 e superiore.

MySQL Proxy è un’applicazione molto leggera (200 KB in compilazione dinamica, 1.5 MB in compilazione statica con le librerie), che è stata disegnata per interporsi fra un client e un server MySQL ed eseguire operazioni sui pacchetti inviati e ricevuti.
Il programma ha poche opzioni di configurazione. La caratteristica che lo rende interessante e funzionale è un interprete Lua integrato, grazie al quale è possibile analizzare ed eventualmente modificare i pacchetti passati fra client e server.
Il client non si accorge del Proxy, che agisce da man in the middle. Il client si connette con le solite credenziali. Il Proxy intercetta la richiesta e si collega al server. Da quel momento, ogni query inviata dal client e i relativi risultati restituiti dal server passano attraverso il Proxy.

Si noti che MySQL Proxy non è un’applicazione di malware, anche se la definizione resa sopra, con la sua possibilità di intercettazione, potrebbe farlo credere. L’uso del Proxy è trasparente per il client, in materia di protocollo, ovvero il client usa il server tramite il Proxy senza avvertire differenze (tranne quando usa funzioni esplicitamente create per il Proxy). Ma il Proxy usa una porta diversa dal server, e pertanto, anche se l’uso è trasparente per l’applicazione, l’amministratore è conscio della sua esistenza. L’uso del Proxy senza consenso di una delle due parti non è possibile. Il Proxy può essere usato dall’amministratore, per ampliare le funzionalità del server, o dall’utente, per lo stesso motivo. Nel primo caso, il Proxy sarà visibile a tutti gli utenti. Nel secondo caso solo l’utente che l’ha installato nella sua macchina è al corrente delle funzioni estese.

Nella sua forma essenziale, MySQL Proxy è uno strumento di ridirezione, che passa un pacchetto di richiesta dal client al server, prende dal server i risultati, e li passa al client. Nel passaggio di dati, il Proxy può intervenire, ed effettuare operazioni sulla query prima che venga inviata, o sui risultati, prima che vengano restituiti. Le modifiche vengono effettuate tramite script in Lua, che usano funzioni predefinite per alterare lo stato dei pacchetti. Le funzioni sono le seguenti:

  • connect_server in cui si può agire al momento della connessione al server;
  • read_handshake che avviene immediatamente dopo la connessione;
  • read_auth in cui si passano al server le credenziali di accesso;
  • read_auth_result dove viene ricevuto il risultato dell’operazione precedente;
  • read_query che si attiva per ogni query inviata al server;
  • read_query_result che viene richiamata quando il Proxy riceve il risultato di una query modificata;
  • disconnect_client che si attiva quando un client viene disconnesso.

Ecco come l’ho configurato ed installato  su Ubuntu per avere uno splitting r/w :

apt-get install mysql-proxy

Mi sono crato uno script dentro /root/scritpt/proxy.sh :
#!/bin/bash

MASTERDB=server1
SLAVEDB01=server2

LUA_PATH="/usr/share/mysql-proxy/?.lua" /usr/sbin/mysql-proxy \
 --daemon \
 --proxy-backend-addresses=$MASTERDB:3306 \
 --proxy-read-only-backend-addresses=$SLAVEDB01:3306 \
 --proxy-lua-script=/usr/share/mysql-proxy/rw-splitting.lua

e gli ho assegnato i permessi di esecuzione con chmod.
Notare che lo script puo’ essere modificato per avere + slave.

 A questo punto facciamo partire automaticamente lo script creando un file in /etc/init.d/mysql-proxy :

#!/bin/bash
#
# mysql-proxy: Start mysql-proxy in daemon mode
#
# Author: OpenX
#
# chkconfig: - 99 01
# description: Start mysql-proxy in daemon mode with r/w splitting
# processname: mysql-proxy
start(){
 echo "Starting mysql-proxy..."
 /root/script/proxy.sh
}
stop(){
  echo "Stopping mysql-proxy..."
  killall mysql-proxy
}

case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
*)
echo "Usage: mysql-proxy {start|stop|restart}"
exit 1
esac

Occhio alle perfomance pero’ ! 
http://www.mysqlperformanceblog.com/2009/06/09/mysql-proxy-urgh-performance-and-scalability/ 

Bash script cambio password

Personalmente me lo sono scrittp per cabiare qualcosa come 54 password ftp.

Non volendolo fare a mano sono ricorso al solito bash

Gli utenti nei sistemi Linux sono contenuti in questo file  /etc/passwd
e si presentano in questo modo :

test.it:x:526:526:test.it:/home/test.it:/bin/sh

Per prima cosa elimino tutto quello che non mi serve :
awk -F":" '{ print $1 }' /etc/passwd > user.txt

ed ottengo quindi solo lo user :
test.it

A questo punto ecco che entra in azione lo script vero e proprio :

#!/bin/bash

function randpass
{
echo `</dev/urandom tr -dc A-Za-z0-9 | head -c8`
}

for i in `more ftp_ok`
do
p=`randpass`
echo $i $p

echo $p | passwd –stdin $i
done

Il gioco è fatto !