Category: Linux System

Posted on

Apache vs Nginx

Apache vs Nginx from here

28 gennaio 2015 Apache, Nginx

Introduzione

Apache e Nginx sono i due server web open source più comuni al mondo. Assieme, sono responsabili della gestione di oltre il 50% del traffico Internet. Entrambe le soluzioni sono in grado di gestire carichi di lavoro di vario tipo e operare con altri software per fornire uno stack web completo.

Mentre Apache e Nginx condividono molte qualità, non dovrebbero essere considerati come del tutto intercambiabili. Ognuno eccelle a modo suo ed è importante comprendere le situazioni in cui potrebbe essere necessario rivalutare quale web server scegliere. Questo articolo sarà dedicato alla discussione su come ciascun server sia più adatto in differenti impieghi.

Panoramica generale

Prima di immergersi nelle differenze tra Apache e Nginx, diamo un rapido sguardo alla storia di questi due progetti e alle loro caratteristiche generali.

Apache

L’ “Apache HTTP Server” è stato creato da Robert McCool nel 1995 ed è stato sviluppato sotto la direzione della Apache Software Foundation dal 1999. Dal momento che il server web HTTP è il progetto originale della fondazione ed è di gran lunga il loro più famoso software, viene spesso chiamato semplicemente “Apache”.

Il server web Apache è il server più popolare su internet fin dal 1996. A causa di questa popolarità, Apache gode di un’ottima documentazione e della completa integrazione con altri software.

Gli amministratori di sistema scelgono di frequente Apache per la sua flessibilità, potenza, e un ampio supporto. È estensibile attraverso un sistema di moduli caricabili dinamicamente e in grado di far funzionare un gran numero di linguaggi interpretati senza dover usare programmi esterni ad Apache stesso.

Nginx

Nel 2002, Igor Sysoev iniziò a lavorare su Nginx in risposta al problema C10K, che è stato una sfida per i server web nell’intraprendere la gestione di diecimila connessioni contemporanee come requisito per un web al passo con i tempi. La prima release pubblica è del 2004, ed ha raggiunto l’obiettivo affidandosi ad una architettura asincrona guidata dagli eventi (events-driven).

Fin dal suo debutto, Nginx ha visto crescere la sua popolarità grazie all’utilizzo minimo delle risorse e la sua capacità di scalare facilmente su un hardware minimale. Nginx eccelle nella gestione rapida dei contenuti statici ed è stato progettato per passare le richieste dinamiche ad altri software più adatti allo scopo.

Gli amministratori di sistema scelgono di frequente Nginx per la sua efficienza nel gestire le risorse e la sua reattività sotto carico. I sostenitori di Nginx sottolineano la sua propensione alle caratteristiche di base da server web e a quelle di server proxy.

Architettura della gestione delle connessioni

Una grande differenza tra Apache e Nginx è il modo vero e proprio in cui gestiscono le connessioni e il traffico. Questa è forse la differenza più significativa nel modo in cui rispondono alle diverse condizioni di traffico.

Apache

Apache fornisce una varietà di moduli multi-processo (Apache li chiama MPM) che indicano il modo in cui vengono gestite le richieste dei client. Fondamentalmente, ciò consente agli amministratori di sistema di cambiare facilmente l’architettura della gestione delle connessioni. Queste architetture sono:

  • mpm_prefork: Per gestire la richiesta, questo modulo genera processi con un singolo thread. Ogni figlio può gestire una sola connessione alla volta. Finché il numero di richieste è inferiore al numero di processi, l’MPM è molto veloce. Tuttavia, le prestazioni degradano rapidamente quando le richieste superano il numero di processi, quindi in determinati contesti non è una buona scelta. Ogni processo ha un impatto significativo sul consumo di RAM, quindi l’MPM è difficile da scalare in maniera efficace. L’MPM può essere ancora una buona scelta se viene utilizzato in combinazione con altri componenti che non sono sono stati pensati per i thread. Ad esempio, il PHP non è thread-safe, quindi l’MPM è raccomandato quale unico modo sicuro di lavorare con mod_php, il modulo Apache per l’elaborazione dei file PHP.
  • mpm_worker: Questo modulo genera processi che possono gestire più thread per ciascuno. Ognuno di questi thread può gestire una singola connessione. I thread sono molto più efficienti rispetto ai processi, il che significa che questo MPM scala meglio rispetto all’MPM prefork. Poiché ci sono più thread che processi, vuol dire anche che le nuove connessioni possono usare immediatamente un thread libero invece di dover attendere un processo libero.
  • mpm_event: Nella maggior parte dei casi, questo modulo è simile al modulo worker, ma è ottimizzato per gestire connessioni keep-alive. Quando si utilizza l’MPM worker, una connessione mantiene un thread indipendentemente dal fatto che ci sia una connessione attiva. L’evento MPM gestisce connessioni keep-alive accantonando dei thread dedicati alla gestione delle connessioni keep-alive e facendo passare le richieste attive ad altri thread. Ciò fa sì che il modulo eviti di rimanere invischiato da richieste keep-alive, permettendo così un’esecuzione più veloce. È stato definito stabile con il rilascio di Apache 2.4.

Come si può vedere, Apache fornisce un’architettura flessibile nella scelta di diversi algoritmi di gestione delle connessioni e delle richieste. Le scelte sono principalmente una funzione dell’evoluzione del server e della crescente necessità di concorrenza, come è stato per l’intera internet.

Nginx

Nginx è salito alla ribalta dopo Apache, con una maggiore consapevolezza sui problemi di concorrenza che si trovano ad affrontare i siti scalabili. Sfruttando questa conoscenza, Nginx è stato progettato da zero ed utilizza un algoritmo asincrono, non-bloccante, di gestione delle connessioni in base agli eventi (event-driven).

Nginx genera processi worker, ognuno dei quali in è grado di gestire migliaia di  connessioni. I processi worker fanno ciò implementando un veloce meccanismo di loop che verifica ed elabora continumanente gli eventi. Il disaccoppiamento dell’effettivo carico di lavoro dalle connessioni permette a ciascun worker di occuparsi di una connessione solo quando viene attivato un nuovo evento.

Ciascuna delle connessioni gestite dal worker viene posta all’interno del loop di eventi dove risiede con le altre connessioni. All’interno del ciclo, gli eventi vengono elaborati in modo asincrono, consentendo all’elaborazione di venire gestita in modo non bloccante. Quando la connessione viene chiusa, viene rimossa dal loop.

Questo stile di elaborazione delle connessioni consente a Nginx di scalare davvero tanto con risorse limitate. Dal momento che il server è single-threaded e i processi non vengono generati per gestire ogni nuova connessione, l’utilizzo della memoria e della CPU tende a rimanere relativamente costante, anche nei momenti di carico pesante.

Contenuto Statico vs Dinamico

In termini di casi d’uso reali, uno dei paragoni più comuni tra Apache e Nginx è il modo in cui ciascun server gestisce le richieste di contenuti statici e dinamici.

Apache

I server Apache sono in grado di gestire i contenuti statici utilizzando l’ordinaria modalità basata sui file. L’esecuzione di queste operazioni è principalmente compito dei metodi MPM sopra descritti.

Apache può elaborare anche contenuti dinamici grazie all’integrazione di un interprete del linguaggio che si vuole usare, in ciascuna delle sue istanze dei worker. Ciò permette di eseguire il contenuto dinamico nel web server stesso, senza dover ricorrere a componenti esterni. Questi interpreti possono essere attivati ​​attraverso l’uso di moduli caricabili dinamicamente.

La capacità di Apache di gestire contenuti dinamici internamente implica che la configurazione dell’esecuzione di contenuti dimanici tende ad essere più semplice. La comunicazione non ha bisogno di essere coordinata con un software aggiuntivo ed i moduli possono essere scambiati facilmente nel caso in cui ci sia un cambiamento di ciò che necessita ai contenuti [per essere processati, NdT].

Nginx

Nginx non ha alcuna capacità di elaborare contenuti dinamici in modo nativo. Per gestire PHP ed altre richieste dal contenuto dinamico, Nginx è costretto a passare l’esecuzione ad un interprete esterno ed attendere di poter reinviare il contenuto elaborato. In tal caso il risultato può essere trasmesso al client.

Per gli amministratori di sistema, ciò significa dover configurare la comunicazione che intercorre tra Nginx e l’interprete attraverso uno dei protocolli che Nginx è in grado di gestire (http, FastCGI, SCGI, uWSGI, memcache). Ciò può complicare leggermente le cose, soprattutto quando si cerca di anticipare il numero di connessioni consentite, dato che verrà utilizzata un’ulteriore connessione per ogni chiamata all’interprete.

Tuttavia, anche questo metodo presenta alcuni vantaggi. Dal momento che l’interprete dinamico non è incorporato nel processo worker, l’overhead dato dall’interprete riguarderà il solo contenuto dinamico. Il contenuto statico può essere servito in un colpo solo e l’interprete sarà chiamato solo quando necessario. Anche Apache può funzionare in questo modo, ma così non si potranno avere i benefici visti nella sezione precedente.

Configurazione Distribuita VS Centralizzata

Per gli amministratori di sistema, una delle differenze che saltano più facilmente all’occhio tra questi due software è se sia consentita o meno una configurazione a livello di directory all’interno delle directory stesse.

Apache

Apache include un’opzione che consente l’uso di configurazioni aggiuntive basate sulle directory. Ciò avviene controllando e intepretando le direttive poste in file nascosti all’interno delle directory stesse. Questi file sono noti come file .htaccess .

Dal momento che questi file risiedono all’interno delle directory stesse, durante la gestione di una richiesta Apache controlla la presenza di un file .htaccess in ogni parte del path del file richiesto e applica le direttive che trova al suo interno. Ciò permette una configurazione decentrata efficace del server web, che viene spesso utilizzata per implementare l’URL rewrite, le restrizioni di accesso, l’autorizzazione e l’autenticazione, ed anche le politiche di caching.

Mentre gli esempi di cui sopra possono essere configurati nel file di configurazione principale di Apache, i file .htaccess hanno alcuni vantaggi importanti. Innanzitutto, poiché i file vengono interpretati ogni volta che vengono trovati in un path della richiesta, il loro scopo trova subito compimento, senza dover far ripartire il server. In secondo luogo rende possibile consentire agli utenti non privilegiati il controllo di alcuni aspetti dei loro contenuti web senza dar loro il controllo sull’intero file di configurazione.

Questo, per alcuni software web come i sistemi di gestione dei contenuti, facilita la configurazione del proprio ambiente senza dover fornire l’accesso al file di configurazione centrale. Ciò viene usato anche dai fornitori di shared hosting per mantenere il controllo della configurazione principale dando allo stesso tempo ai clienti il ​​controllo sulle proprie  specifiche directory.

Nginx

Nginx non interpreta file .htaccess né fornisce alcun meccanismo per valutare una configurazione per directory al di fuori del file di configurazione principale. Ciò può essere meno flessibile rispetto al modello di Apache, ma ha i suoi vantaggi.

Il miglioramento più importane rispetto al sistema di configurazione a livello di directory offerto da .htaccess, è l’aumento delle prestazioni. Per una tipica configurazione di Apache che può consentire un .htaccess in ogni directory, il server verifica la presenza di questi file in ognuna delle directory genitore che portano al file richiesto, per ogni richiesta. Se in questa ricerca vengono trovati uno o più file .htaccess, devono essere letti e interpretati. Non permettendo l’override delle directory, Nginx può servire richieste più velocemente facendo una sola ricerca della directory e una sola lettura di file per ogni richiesta (assumendo che il file si trovi nella struttura convenzionale della directory).

Un altro vantaggio è legato alla sicurezza. Distribuire l’accesso alle configurazioni a livello di directory distribuisce anche la responsabilità della sicurezza ai singoli utenti, sui quali non si dovrebbe far affidamento per una corretta gestione di questo compito. La garanzia che l’amministratore mangenga il controllo sull’intero web server è in grado di prevenire alcuni passi falsi riguardanti la sicurezza che possono verificarsi quando l’accesso è dato a terzi.

Se queste preoccupazioni vi saltano all’orecchio, tenete a mente che in Apache è possibile disattivare l’interpretazione degli .htaccess.

Interpretazione basata sui file vs interpretazione basata su URI

Un’altra area nella quale i due server differiscono è il modo in cui il server web interpreta le richieste e le associa alle effettive risorse del sistema.

Apache

Apache ha la capacità di interpretare una richiesta come una risorsa fisica sul filesystem o come un URI che necessita di una valutazione più astratta. In generale, nel primo caso Apache utilizza i blocchi <Directory> o <Files>, nel caso di risorse più astratte utilizza i blocchi <Location>.

Dato che Apache è il risultato di una progettazione di un web server da zero, il comportamento predefinito è di solito quello di interpretare le richieste come risorse del file system. Si inizia prendendo la directory root del documento, aggiungendo la parte della richiesta seguita dal numero di host e dalla porta per cercare di trovare un file vero e proprio. In sostanza, la gerarchia del filesystem è rappresentata sul web come l’albero dei documenti raggiungibili.

Apache fornisce una serie di alternative per i casi in cui la richiesta non trova corrispondenza al filesystem sottostante. Per esempio, una direttiva Alias può essere utilizzata per mappare ad una posizione alternativa. Usare i blocchi <Location> è un metodo per lavorare con l’URI stesso anziché con il filesystem. Ci sono anche varianti con le espressioni regolari che possono essere utilizzate per usare la configurazione sul filesystem in maniera più flessibile.

Sebbene Apache sia in grado di operare sia sul filesystem sottostante sia sullo spazio web, fa pesantemente affidamento alle funzioni del filesystem. Ce ne si può rendere conto in alcune delle decisioni nella progettazione, compreso l’uso dei file .htaccess per la configurazione a directory. Nei casi in cui la richiesta rispecchia il filesystem sottostante, è la stessa documentazione Apache (Apache Docs) a diffidare dall’utilizzo dei blocchi basati sugli URI per la limitazione dell’accesso.

Nginx

Nginx è stato creato per essere sia un server web che un server proxy. A causa dell’architettura richiesta per questi due ruoli, Nginx lavora principalmente con gli URI, facendone la trasposizione al file system quando necessario.

Ce ne si può rendere conto in certi modi in cui i file di configurazione di Nginx sono costruiti ed interpretati. Nginx non prevede un meccanismo per specificare la configurazione di una directory del filesystem, analizza invece l’URI stesso.

Ad esempio, i blocchi di configurazione principali per Nginx sono i blocchi server e location. Il blocco server interpreta l’host richiesto, mentre i blocchi location sono responsabili della ricerca di una corrispondenza con porzioni di URI che stanno dopo l’host e la porta. A questo punto, la richiesta viene interpretata come un URI e non come una posizione nel filesystem.

Per i file statici, tutte le richieste alla fine devono essere mappate su un percorso nel filesystem. In primo luogo, Nginx seleziona i blocchi server e location che gestiranno la richiesta e quindi unisce la directory root del documento con l’URI, adattando tutto ciò che è necessario in base alla configurazione specificata.

Ciò potrà sembrare dello stesso tipo [di quella di Apache, NdT], ma fare come prima cosa il parsing delle richieste come URI invece che come posizioni nel filesystem, consente a Nginx di operare più facilmente in ambedue i ruori di  server web/mail e di server proxy. Nginx viene configurato impostando semplicemente il modo di rispondere a diversi pattern di richiesta. Nginx non controlla il filesystem fino a quando non è pronto a servire la richiesta, il che spiega il motivo per cui non utilizza un formato tipo i file .htaccess.

Moduli

Sia Nginx che Apache sono espandibili attraverso dei sistemi a moduli , ma il modo in cui operano differisce in modo significativo.

Apache

Il sistema modulare di Apache permette di caricare o scaricare moduli in modo dinamico in modo da soddisfare ogni esigenza nel corso dell’esecuzione del server. Il nucleo di Apache è sempre presente, mentre i moduli possono essere attivati ​​o disattivati, aggiungendo o rimuovendo funzionalità aggiuntive e hook [tecnica di codifica di un programma che permette all’utente di estenderlo, NdT] al server principale.

Apache utilizza questa funzionalità per una grande varietà di compiti. Grazie alla maturità della piattaforma, vi è una vasta disponibilità di moduli. Questi moduli possono essere utilizzati per modificare alcune delle funzionalità di base del server, per esempio mod_php che incorpora un interprete PHP in ciascun worker in esecuzione.

I moduli però non sono limitati al trattamento dei contenuti dinamici. Tra le altre funzioni, i moduli possono essere utilizzati per la riscrittura degli URL, l’autenticazione dei client, l’hardening del server, il log, il caching, la compressione, le funzioni di proxy, la limitazione della banda e la cifratura. I moduli dinamici possono estendere le funzionalità di base in modo significativo senza richiedere troppo lavoro extra.

Nginx

Anche Nginx implementa un sistema modulare, ma è piuttosto diverso dal sistema Apache. In Nginx, i moduli non sono caricabili dinamicamente, quindi devono essere scelti e compilati nel programma principale.

Per molti utenti, ciò rende Nginx molto meno flessibile. Questo è vero soprattutto per gli utenti a cui non piace mantenere le proprie versioni dei programmi compilati al di fuori del tradizionale sistema di gestione dei pacchetti della distribuzione. Mentre i pacchetti delle distribuzioni tendono ad includere i moduli più comuni, se si ha bisogno di un modulo non standard si dovrà compilare da sé il server dai sorgenti.

I moduli Nginx sono tuttavia molto utili e permettono di far fare al server ciò che si desidera semplicemente includendo la funzionalità che si intende utilizzare. Qualche utente potrebbe anche considere tutto ciò più sicuro, visto che non si possono far caricare al server delle componenti arbitrarie. Tuttavia, se il server viene sempre lasciato in una modalità in cui questo è possibile, è probabile che sia già compromesso.

I moduli Nginx permettono molte delle stesse funzionalità dei moduli di Apache. Ad esempio, i moduli Nginx sono in grado di fornire il supporto proxy, la compressione, la limitazione di banda, il logging, la riscrittura, la geolocalizzazione, l’autenticazione, la crittografia, lo streaming e le funzionalità di posta elettronica.

Supporto, Compatibilità, Ecosistema e Documentazione

Un punto importante da considerare è che il vero modo per rendere un sistema funzionante sarà dato dall’offerta di assistenza e supporto disponibile con altri software.

Apache

Visto che Apache è stato popolare per così tanto tempo, il supporto per il server è discretamente onnipresente. È disponibile una grande quantità di documentazione ufficiale e di terze parti per il server principale e per i casi che coinvolgono Apache con altri software.

Assieme alla documentazione, molti strumenti e progetti web includono strumenti che permettono a questi strumenti e progetti stessi, il bootstrap all’interno di un ambiente di Apache. Questo ambiente può essere incluso nei progetti stessi, o nei pacchetti manutenuti dalle persone che si occupano dei pacchetti della vostra distribuzione.

Apache, in generale, troverà maggiore supporto in progetti di terze parti semplicemente per la sua quota di mercato e per il periodo di tempo da cui è disponibile. Gli amministratori di sistema hanno una più alta probabilità di avere pratica con Apache, non solo a causa della sua diffusione, ma anche perché molte persone cominciano con lo shared hosting che si basa quasi esclusivamente su Apache a causa delle capacità di gestione distribuita, possibili grazie ad .htaccess .

Nginx

Nginx sta avendo un supporto crescente visto che sempre più utenti lo adottano per la sua attitudine alle prestazioni pure, ma ha ancora un po’ di ritardo da recuperare in alcuni settori chiave.

In passato era difficile trovare della documentazione completa riguardante Nginx in lingua ingles , perché la maggior parte dello sviluppo iniziale e la documentazione erano in russo. Dal momento che l’interesse per il progetto è cresciuto, la documentazione è stata completata e ora ci sono un sacco di risorse sulla gestione di Nginx sul sito ufficiale e non.

Per quanto riguarda le applicazioni di terze parti, il supporto e la documentazione stanno diventando disponibili con sempre più facilità e i manutentori dei pacchetti stanno cominciando, in alcuni casi, a fornire la scelta tra la configurazione automatica per Apache e quella per Nginx. Anche senza supporto, la configurazione di Nginx per poter funzionare con software alternativo è di solito chiara, a condizione che il progetto stesso documenti le sue esigenze (permessi, header, ecc.).

Uso combinato di Apache e Nginx

Andando oltre i vantaggi e i limiti sia di Apache che di Nginx , si può avere un’idea migliore di quale server sia più adatto alle vostre esigenze. Tuttavia, molti utenti trovano fattibile sfruttare i punti di forza di ciascun server usandoli assieme.

La tipica configurazione usata per ottenere questa collaborazione è quella di mettere Nginx a precedere Apache come proxy inverso. Ciò permetterà a Nginx di gestire tutte le richieste da parte dei client. Questo sfrutta la rapida velocità di elaborazione di Nginx e la sua capacità di gestire un gran numero di connessioni contemporaneamente.

Per i contenuti statici, nei quali Nginx eccelle, i file saranno serviti velocemente e direttamente al client. Per i contenuti dinamici, per esempio i file PHP, Nginx delegherà la richiesta ad Apache, che può così elaborare i risultati e restituire la pagina elaborata. Nginx può quindi passare il contenuto al client.

Questa configurazione funziona bene per molte persone, perché permette a Nginx di funzionare come una macchina di smistamento. Essa si occuperà di tutte le richieste che potrà e lascerà passare quelle che non riesce a servire nativamente. Riducendo le richieste che il server Apache è chiamato a gestire, siamo in grado di attenuare alcuni dei blocchi che si verificano quando un processo o un thread di Apache è occupato.

Questa configurazione permette anche di scalare, tramite l’aggiunta di server di backend aggiuntivi quando ve ne sarà bisogno. Nginx può essere configurato per migrare facilmente su un gruppo di server, aumentando la resilienza al fallimento e le prestazioni di questa configurazione.

Conclusioni

Come si può vedere, sia Apache che Nginx sono potenti, flessibili e fanno quello che devono. La decisione su quale server sia per voi il migliore si deve in gran parte alla valutazione delle vostre specifiche esigenze e dai test effettuati con i modelli che ci si aspetta di ottenere.

Ci sono differenze tra i progetti che hanno un impatto davvero importante sulle prestazioni vere e proprie, quelli sulle capacità, e quelli sul tempo di implementazione necessari per ottenere ciascuna soluzione funzionante. Tuttavia, queste soluzioni sono di solito il risultato di una serie di compromessi che non dovrebbero essere scartati con noncuranza. Alla fine, non ci sono web server che vanno bene per tutto, dunque usate la soluzione che meglio si adatta ai i vostri obiettivi.

Posted on

Fail2ban Error in file postfix-sasl.conf

my old file conf was :
failregex = ^%(__prefix_line)swarning: [-._\w]+\[\]: SASL ((?i)LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(:[ A-Za-z0-9+/:]*={0,2})?\s*$

If you go to https://regex101.com/ you can test the regular expression on the log string :

May 10 15:57:59 mail postfix/smtpd[28617]: warning: ip43.ip-192-99-125.net[192.99.125.43]: SASL LOGIN authentication failed: Connection lost to authentication server

I corrected the error and the the configuration is :

failregex = ^%(__prefix_line)swarning: [-._\w]+\[<HOST>\]: SASL ((?i)LOGIN|PLAIN|(?:CRAM|DIGEST)-MD5) authentication failed(:[ A-Za-z0-9+:]*={0,2})?\s*$

You can leave also the first setting but it is not necessary.

Some others command to do test:

fail2ban-client ping
fail2ban-client status
fail2ban-client status dovecot
fail2ban-client status postfix-sasl

fail2ban-regex /root/software/test_fail2ban_dovecot.log /etc/fail2ban/filter.d/dovecot.conf

You can test a piece of log file with a configuration jail file using the command fail2ban-regex

1a -> no need to change rotation, read about the settings: bantime, findtime, maxretry
1b -> fail2ban reads the log which is defined in jails logpath, for the recidive jail /var/log/fail2ban.log will be used
2 -> yes it means recidve will ban ip based on the log entrys matching bantime, findtime, maxretry
3. -> such long block time should not be needed, if it is an repeating offender he will by chached up by the recidive jail
4. it depends on your system and resources, if you are worry about the amount of blocked ip´s then you can set up the jails with ipset,

read also:
Using Fail2ban to Secure Your Server – A Tutorial
Optimising your Fail2Ban filters | The Art of Web
Protection Against Brute Force Attacks (Fail2Ban)
Fail2Ban Jails Management

fail2ban-client set <jail> unbanip <ip>

Posted on

Bach color Linux

# Reset
Color_Off='\033[0m'       # Text Reset

# Regular Colors
Black='\033[0;30m'        # Black
Red='\033[0;31m'          # Red
Green='\033[0;32m'        # Green
Yellow='\033[0;33m'       # Yellow
Blue='\033[0;34m'         # Blue
Purple='\033[0;35m'       # Purple
Cyan='\033[0;36m'         # Cyan
White='\033[0;37m'        # White

# Bold
BBlack='\033[1;30m'       # Black
BRed='\033[1;31m'         # Red
BGreen='\033[1;32m'       # Green
BYellow='\033[1;33m'      # Yellow
BBlue='\033[1;34m'        # Blue
BPurple='\033[1;35m'      # Purple
BCyan='\033[1;36m'        # Cyan
BWhite='\033[1;37m'       # White

# Underline
UBlack='\033[4;30m'       # Black
URed='\033[4;31m'         # Red
UGreen='\033[4;32m'       # Green
UYellow='\033[4;33m'      # Yellow
UBlue='\033[4;34m'        # Blue
UPurple='\033[4;35m'      # Purple
UCyan='\033[4;36m'        # Cyan
UWhite='\033[4;37m'       # White

# Background
On_Black='\033[40m'       # Black
On_Red='\033[41m'         # Red
On_Green='\033[42m'       # Green
On_Yellow='\033[43m'      # Yellow
On_Blue='\033[44m'        # Blue
On_Purple='\033[45m'      # Purple
On_Cyan='\033[46m'        # Cyan
On_White='\033[47m'       # White

# High Intensity
IBlack='\033[0;90m'       # Black
IRed='\033[0;91m'         # Red
IGreen='\033[0;92m'       # Green
IYellow='\033[0;93m'      # Yellow
IBlue='\033[0;94m'        # Blue
IPurple='\033[0;95m'      # Purple
ICyan='\033[0;96m'        # Cyan
IWhite='\033[0;97m'       # White

# Bold High Intensity
BIBlack='\033[1;90m'      # Black
BIRed='\033[1;91m'        # Red
BIGreen='\033[1;92m'      # Green
BIYellow='\033[1;93m'     # Yellow
BIBlue='\033[1;94m'       # Blue
BIPurple='\033[1;95m'     # Purple
BICyan='\033[1;96m'       # Cyan
BIWhite='\033[1;97m'      # White

# High Intensity backgrounds
On_IBlack='\033[0;100m'   # Black
On_IRed='\033[0;101m'     # Red
On_IGreen='\033[0;102m'   # Green
On_IYellow='\033[0;103m'  # Yellow
On_IBlue='\033[0;104m'    # Blue
On_IPurple='\033[0;105m'  # Purple
On_ICyan='\033[0;106m'    # Cyan
On_IWhite='\033[0;107m'   # White

the escape character in bash, hex and octal respectively:

|       | bash  | hex    | octal   | NOTE                         |
|-------+-------+--------+---------+------------------------------|
| start | \e    | \x1b   | \033    |                              |
| start | \E    | \x1B   | -       | x cannot be capital          |
| end   | \e[0m | \x1m0m | \033[0m |                              |
| end   | \e[m  | \x1b[m | \033[m  | 0 is appended if you omit it |
|       |       |        |         |                              |

short example:

| color       | bash         | hex            | octal          | NOTE                                  |
|-------------+--------------+----------------+----------------+---------------------------------------|
| start green | \e[32m<text> | \x1b[32m<text> | \033[32m<text> | m is NOT optional                     |
| reset       | <text>\e[0m  | <text>\1xb[0m  | <text>\033[om  | o is optional (do it as best practice |
|             |              |                |                |                                       |

bash exception:

If you are going to use these codes in your special bash variables

  • PS0
  • PS1
  • PS2 (= this is for prompting)
  • PS4

you should add extra escape characters so that  can interpret them correctly. Without this adding extra escape characters it works but you will face problems when you use Ctrl + r for search in your history.

exception rule for bash

You should add \[ before any starting ANSI code and add \] after any ending ones.
Example:
in regular usage: \033[32mThis is in green\033[0m
for PS0/1/2/4: \[\033[32m\]This is in green\[\033[m\]

\[ is for start of a sequence of non-printable characters
\] is for end of a sequence of non-printable characters

Tip: for memorize it you can first add \[\] and then put your ANSI code between them:
– \[start-ANSI-code\]
– \[end-ANSI-code\]

type of color sequence:

  1. 3/4 bit
  2. 8 bit
  3. 24 bit

Before diving into these colors, you should know about 4 modes with these codes:

1. color-mode

It modifies the style of color NOT text. For example make the color bright or darker.

  • 0 reset
  • 1; lighter than normal
  • 2; darker than normal

This mode is not supported widely. It is fully support on Gnome-Terminal.

2. text-mode

This mode is for modifying the style of text NOT color.

  • 3; italic
  • 4; underline
  • 5; blinking (slow)
  • 6; blinking (fast)
  • 7; reverse
  • 8; hide
  • 9; cross-out

and are almost supported.
For example KDE-Konsole supports 5; but Gnome-Terminal does not and Gnome supports 8;but KDE does not.

3. foreground mode

This mode is for colorizing the foreground.

4. background mode

This mode is for colorizing the background.

The below table shows a summary of 3/4 bit version of ANSI-color

|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
| color-mode | octal    | hex     | bash  | description      | example (= in octal)         | NOTE                                 |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|          0 | \033[0m  | \x1b[0m | \e[0m | reset any affect | echo -e "\033[0m"            | 0m equals to m                       |
|          1 | \033[1m  |         |       | light (= bright) | echo -e "\033[1m####\033[m"  | -                                    |
|          2 | \033[2m  |         |       | dark (= fade)    | echo -e "\033[2m####\033[m"  | -                                    |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|  text-mode | ~        |         |       | ~                | ~                            | ~                                    |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|          3 | \033[3m  |         |       | italic           | echo -e "\033[3m####\033[m"  |                                      |
|          4 | \033[4m  |         |       | underline        | echo -e "\033[4m####\033[m"  |                                      |
|          5 | \033[5m  |         |       | blink (slow)     | echo -e "\033[3m####\033[m"  |                                      |
|          6 | \033[6m  |         |       | blink (fast)     | ?                            | not wildly support                   |
|          7 | \003[7m  |         |       | reverse          | echo -e "\033[7m####\033[m"  | it affects the background/foreground |
|          8 | \033[8m  |         |       | hide             | echo -e "\033[8m####\033[m"  | it affects the background/foreground |
|          9 | \033[9m  |         |       | cross            | echo -e "\033[9m####\033[m"  |                                      |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
| foreground | ~        |         |       | ~                | ~                            | ~                                    |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|         30 | \033[30m |         |       | black            | echo -e "\033[30m####\033[m" |                                      |
|         31 | \033[31m |         |       | red              | echo -e "\033[31m####\033[m" |                                      |
|         32 | \033[32m |         |       | green            | echo -e "\033[32m####\033[m" |                                      |
|         33 | \033[32m |         |       | yellow           | echo -e "\033[33m####\033[m" |                                      |
|         34 | \033[32m |         |       | blue             | echo -e "\033[34m####\033[m" |                                      |
|         35 | \033[32m |         |       | purple           | echo -e "\033[35m####\033[m" | real name: magenta = reddish-purple  |
|         36 | \033[32m |         |       | cyan             | echo -e "\033[36m####\033[m" |                                      |
|         37 | \033[32m |         |       | white            | echo -e "\033[37m####\033[m" |                                      |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|         38 | 8/24     |                    This is for special use of 8-bit or 24-bit                                            |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
| background | ~        |         |       | ~                | ~                            | ~                                    |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|         40 | \033[40m |         |       | black            | echo -e "\033[40m####\033[m" |                                      |
|         41 | \033[41m |         |       | red              | echo -e "\033[41m####\033[m" |                                      |
|         42 | \033[42m |         |       | green            | echo -e "\033[42m####\033[m" |                                      |
|         43 | \033[43m |         |       | yellow           | echo -e "\033[43m####\033[m" |                                      |
|         44 | \033[44m |         |       | blue             | echo -e "\033[44m####\033[m" |                                      |
|         45 | \033[45m |         |       | purple           | echo -e "\033[45m####\033[m" | real name: magenta = reddish-purple  |
|         46 | \033[46m |         |       | cyan             | echo -e "\033[46m####\033[m" |                                      |
|         47 | \033[47m |         |       | white            | echo -e "\033[47m####\033[m" |                                      |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|
|         48 | 8/24     |                    This is for special use of 8-bit or 24-bit                                            |                                                                                       |
|------------+----------+---------+-------+------------------+------------------------------+--------------------------------------|

The below table shows a summary of 8 bit version of ANSI-color

|------------+-----------+-----------+---------+------------------+------------------------------------+-------------------------|
| foreground | octal     | hex       | bash    | description      | example                            | NOTE                    |
|------------+-----------+-----------+---------+------------------+------------------------------------+-------------------------|
|        0-7 | \033[38;5 | \x1b[38;5 | \e[38;5 | standard. normal | echo -e '\033[38;5;1m####\033[m'   |                         |
|       8-15 |           |           |         | standard. light  | echo -e '\033[38;5;9m####\033[m'   |                         |
|     16-231 |           |           |         | more resolution  | echo -e '\033[38;5;45m####\033[m'  | has no specific pattern |
|    232-255 |           |           |         |                  | echo -e '\033[38;5;242m####\033[m' | from black to white     |
|------------+-----------+-----------+---------+------------------+------------------------------------+-------------------------|
| foreground | octal     | hex       | bash    | description      | example                            | NOTE                    |
|------------+-----------+-----------+---------+------------------+------------------------------------+-------------------------|
|        0-7 |           |           |         | standard. normal | echo -e '\033[48;5;1m####\033[m'   |                         |
|       8-15 |           |           |         | standard. light  | echo -e '\033[48;5;9m####\033[m'   |                         |
|     16-231 |           |           |         | more resolution  | echo -e '\033[48;5;45m####\033[m'  |                         |
|    232-255 |           |           |         |                  | echo -e '\033[48;5;242m####\033[m' | from black to white     |
|------------+-----------+-----------+---------+------------------+------------------------------------+-------------------------|

The 8-bit fast test:
for code in {0..255}; do echo -e "\e[38;05;${code}m $code: Test"; done

The below table shows a summary of 24 bit version of ANSI-color

|------------+-----------+-----------+---------+-------------+------------------------------------------+-----------------|
| foreground | octal     | hex       | bash    | description | example                                  | NOTE            |
|------------+-----------+-----------+---------+-------------+------------------------------------------+-----------------|
|      0-255 | \033[38;2 | \x1b[38;2 | \e[38;2 | R = red     | echo -e '\033[38;2;255;0;02m####\033[m'  | R=255, G=0, B=0 |
|      0-255 | \033[38;2 | \x1b[38;2 | \e[38;2 | G = green   | echo -e '\033[38;2;;0;255;02m####\033[m' | R=0, G=255, B=0 |
|      0-255 | \033[38;2 | \x1b[38;2 | \e[38;2 | B = blue    | echo -e '\033[38;2;0;0;2552m####\033[m'  | R=0, G=0, B=255 |
|------------+-----------+-----------+---------+-------------+------------------------------------------+-----------------|
| background | octal     | hex       | bash    | description | example                                  | NOTE            |
|------------+-----------+-----------+---------+-------------+------------------------------------------+-----------------|
|      0-255 | \033[48;2 | \x1b[48;2 | \e[48;2 | R = red     | echo -e '\033[48;2;255;0;02m####\033[m'  | R=255, G=0, B=0 |
|      0-255 | \033[48;2 | \x1b[48;2 | \e[48;2 | G = green   | echo -e '\033[48;2;;0;255;02m####\033[m' | R=0, G=255, B=0 |
|      0-255 | \033[48;2 | \x1b[48;2 | \e[48;2 | B = blue    | echo -e '\033[48;2;0;0;2552m####\033[m'  | R=0, G=0, B=255 |
|------------+-----------+-----------+---------+-------------+------------------------------------------+-----------------|

some screen-shots

foreground 8-bit summary in a .gif

foreground.gif

background 8-bit summary in a .gif

background.gif

color summary with their values

enter image description here enter image description here enter image description here enter image description here

blinking on KDE-Terminal

KDE-blinking

 a simple C code that shows you more

cecho_screenshot

 a more advanced tool that I developed to deal with these colors:
bline

color-mode shot

fade-normal-bright

text mode shot

only-text-mode

combining is OK

combine

more shots

Tips and Tricks for Advanced Users and Programmers:

Can we use these codes in a programming language?

Yes, you can. I experienced in , , ,  , 

Are they slow down the speed of a program?

I think, NO.

Can we use these on Windows?

3/4-bit Yes, if you compile the code with gcc
some screen-shots on Win-7

How to calculate the length of code?

\033[ = 2, other parts 1

Where can we use these codes?

Anywhere that has a tty interpreter
xterm, gnome-terminal, kde-terminal, mysql-client-CLI and so on.
For example if you want to colorize your output with mysql you can use Perl

#!/usr/bin/perl -n
print "\033[1m\033[31m$1\033[36m$2\033[32m$3\033[33m$4\033[m" while /([|+-]+)|([0-9]+)|([a-zA-Z_]+)|([^\w])/g;

store this code in a file name: pcc (= Perl Colorize Character) and then put the file a in valid PATHthen use it anywhere you like.

ls | pcc
df | pcc

inside mysql first register it for pager and then try:

[user2:db2] pager pcc
PAGER set to 'pcc'
[user2:db2] select * from table-name;

pcc

It does NOT handle Unicode.

Do these codes only do colorizing?

No, they can do a lot of interesting things. Try:

echo -e '\033[2K'  # clear the screen and do not move the position

or:

echo -e '\033[2J\033[u' # clear the screen and reset the position

There are a lot of beginners that want to clear the screen with system( "clear" ) so you can use this instead of system(3) call

Are they available in Unicode?

Yes. \u001b

Which version of these colors is preferable?

It is easy to use 3/4-bit, but it is much accurate and beautiful to use 24-bit.
If you do not have experience with  so here is a quick tutorial:
24 bits means: 00000000 and 00000000 and 00000000. Each 8-bit is for a specific color.
24..17 is for  and 16..9 for  and 8..1 for 
So in  #FF0000 means  and here it is: 255;0;0
in  #00FF00 means  which here is: 0;255;0
Does that make sense? what color you want combine it with these three 8-bit values.

reference:
Wikipedia
ANSI escape sequences
tldp.org
tldp.org
misc.flogisoft.com
some blogs/web-pages that I do not remember

Posted on

Running Tomcat Automatically At Linux Startup

A potential drawback of installing Tomcat from a binary distribution instead of using a Linux-packaged version is that you’ll have to do some extra legwork to make Tomcat start automatically when Linux boots up.  To make this process easy and pain-free, follow this simple guide.

Step 1 – Create A Tomcat-Specific User and User Group

It’s a bad idea to run Tomcat as the root user, especially if you’re going to be starting Tomcat automatically.  It’s much more secure to create a new group and user specifically to run Tomcat.  You can do so with the following commands (in this example, we have created a user group named tomcat, and a user named tomcat with the password tomcat; you can certainly be more creative if you wish):

$ groupadd tomcat
$ useradd -s /sbin/nologin -g tomcat -d /path/to/tomcat tomcat

or
$ useradd -r -s /sbin/nologin tomcat

-r for system user
$ passwd tomcat

-r, –system
Create a system account.

System users will be created with no aging information in /etc/shadow, and their
numeric identifiers are chosen in the SYS_UID_MIN-SYS_UID_MAX range, defined in
/etc/login.defs, instead of UID_MIN-UID_MAX (and their GID counterparts for the
creation of groups).

Note that useradd will not create a home directory for such an user, regardless
of the default setting in /etc/login.defs (CREATE_HOME). You have to specify the
-m options if you want a home directory for a system account to be created.

-s, –shell SHELL
The name of the user’s login shell. The default is to leave this field blank,
which causes the system to select the default login shell specified by the SHELL
variable in /etc/default/useradd, or an empty string by default.

Esample:

useradd -m -d /home/thenewuser -s /bin/bash -c "the new user" -U thenewuser

-c “message” : extra information about the user.

-U thenewuser : Create a group with the same name as the user, and add the user to this group.

-N : the -N argument tells the system not to create a group having the user’s name

-m, –create-home are same: Create the user’s home directory if it does not exist.

-d, –home HOME_DIR : The new user will be created using HOME_DIR as the value for the user’s login directory.
if -d is not used the default homedirectory will be /home/thenewuser

-m -d /data/thenewuser : the -m argument creates the /data/thenewuser homedirectory, specified by the -d argument.

-M : the -M argument tells the system not to create a home directory

-s /bin/bash : the -s is used for specifing the user’s default shell, /bin/bash in this case.

-s or –shell are same.

-s /sbin/nologin : The /sbin/nologin for Fedora and /usr/sbin/nologin for Debian are two shells that return you a polite message like “this account is not available” and do not allow you to log into the system. This message can be customized.

-s /bin/false : Is an old shell used to deny a user’s login. The /bin/false exits immediatly when false exists. The user accounts with /bin/false or /bin/true as their default shells are locked.

-s /sbin/nologin belongs to unix-linux while /bin/false part of GNU Coreutils. These shells must be listed in the /etc/shells file, to work.

The users with /sbin/nologin (or /usr/sbin/nologin) can connect through ssh or ftp, but the users with /bin/false are completely locked out from the system.

with useradd -D : You can also view the default parameters set for new user to be created using

# useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel
CREATE_MAIL_SPOOL=yes
#

Step 2 – Adjust Ownership For New Users And Groups

Now that you have created a user to run Tomcat, you’ll need to give them access to the correct directories.  Use the following commands, substituting your own usernames and groups as necessary:

# chown -R tomcat.tomcat /path/to/tomcat
# chmod 775 /path/to/tomcat/webapps
The first gives ownership of the Tomcat directories to the Tomcat user, and the second gives the user write access for the webapps directory.

Step 3 – Relay Traffic For Non-Root Tomcat User

When running Tomcat as a user other than the root user, you will not be able to bind to port 80, which is where Tomcat listens for HTTP requests.  To get around this, you can use Netfilter, which is packaged with all major Linux distributions:

# iptables -t nat -I PREROUTING -p tcp –dport 80 -j REDIRECT –to-ports 8080
# iptables -t nat -I OUTPUT -p tcp –dport 80 -j REDIRECT –to-ports 8080
To preserve these rules through re-boot, save them with the “ip-tables-save” command, and then follow the procedure appropriate for your Linux distribution (for most distributions, this means editing the iptables init script; Debian users should load the configuration via a script called by if-up.d or pre-up.d).

Step 3 – Create A Custom init Script

To start Tomcat at Linux boot time, we’ll need to create an init script that calls the startup.sh and shutdown.sh scripts included with Tomcat.

The actual creation of this script is outside the scope of this article, but there are many useful resources available online.  All you need to know in order to use the basic init script format to call Tomcat is how the startup.sh and shutdown.sh scripts work.

For more information about these scripts, visit our Tomcat Start page, which includes a simple, step-by-step guide to Tomcat’s three start-up shell scripts.

like :

chmod 774 /opt/apache-tomcat-8.0.12-1/ -Rf

export JAVA_OPTS=”-agentlib:hprof=cpu=samples,file=/var/log/cpuTest.log”

#/opt/apache-tomcat-8.0.12-2/bin/startup.sh
TOMCAT_OWNER=tomcat;
export TOMCAT_OWNER

CATALINA_HOME=/opt/apache-tomcat-8.0.12-2;
export CATALINA_HOME

/bin/su -s /bin/bash $TOMCAT_OWNER -c $CATALINA_HOME/bin/startup.sh