Visualizzazione post con etichetta admin. Mostra tutti i post
Visualizzazione post con etichetta admin. Mostra tutti i post

martedì 29 marzo 2016

Bilanciare due Tomcat con apache 2.4

Capita spesso di dover realizzare un servizio session-less che punti a due o più nodi di tomcat pilotati da un classico balancer di apache2.

Ecco l'esperimento su una macchina virtuale.


mercoledì 13 giugno 2012

MongoDB - decode failed on shell




PRIMARY> show dbs;
Wed Jun 13 10:45:05 decode failed. probably invalid utf-8 string [pJ@??]
Wed Jun 13 10:45:05 why: TypeError: malformed UTF-8 character sequence at offset 3
Wed Jun 13 10:45:05 Error: invalid utf8 shell/utils.js:1237


AAAAAAA!!!!!!!

/etc/init.d/mongodb stop
/etc/init.d/mongodb start

PRIMARY> show dbs;
admin 0.203125GB
db0 0.203125GB
db1 0.453125GB
db2 0.203125GB
db3 0.203125G
...
...
..


OK!!!! 




martedì 5 giugno 2012

MongoDB - Configurare l'Auth su sistemi in ReplicaSet/Shared



Procedura da eseguire su ogni server. (testata su Ubuntu con MongoDB versione 10gen)

editare il file:
/etc/mongodb.conf

modificare i parametri:
auth = true
keyFile = /var/lib/mongodb/key


da terminale ssh:
echo "inserire_una_password_che_si_vuole" > /var/lib/mongodb/key
chmod 600 /var/lib/mongodb/key
chown mongodb:mongodb /var/lib/mongodb/key


-- MongoDB restart

eseguire questa operazione su tutti i server che si connettono tra di loro.


-----

connettersi via console su una dei server.
creare l'utente principale di admin che accede a tutto 

use admin;
db.addUser("mongoadm", "345098340958");
db.auth("mongoadm", "345098340958");


Connettersi al db che si vuole e creare le utenze di accesso:

use db1;
db.addUser("user1-db1", "5396739759075ghdfoger");
db.addUser("user2-db1", "46734345t345345")
db.system.users.find();


use db2;
db.addUser("user1-db2", "345345345");
db.addUser("user2-db2", "dgfdfgerter");
db.system.users.find();


a questo punto dai nostri client possiamo connetterci con l'utente del singolo db.
-----


per autenticarsi da console passare sempre dall'utente di admin altrimenti non si accede a tutti i comandi di administration es: rs.status();


Per accedere a db1 da console:

use admin;
db.auth("mongoadm", "345098340958");

use db1;
db.auth("user1-db1", "5396739759075ghdfoger");

mercoledì 16 maggio 2012

MongoDB - 10Gen - MMS

Questo servizio è una valida alternativa al il monitoraggio classico manuale dei db di mongo, basta installare un piccolo agent su uno dei server (ne basta uno solo che abbia accesso in struttura a tutti gli altri).

Il test è stato fatto sulla versione di Ubuntu.

registrarsi sul sito: https://mms.10gen.com

apt-get install python-setuptools
apt-get install build-essential python-dev -- (44,3 MB)
easy_install pip
pip uninstall pymongo (si prova al massimo questa da errore se non installato)
pip install pymongo


scaricare il pacco dalla 10gen a questo indirizzo

https://mms.10gen.com/settings/10gen-mms-agent.zip

eseguire unzip del file appena scaricato.

Andare sulla pagina https://mms.10gen.com/settings e recuperare le chiavi @API_KEY@ e @SECRET_KEY@.

Editare il file settings.py e modificare le chiavi di accesso.

Mandare in esecuzione lo script:
nohup python agent.py > agent.log 2>&1 &

a questo punto l'agent comunica direttamente con il server della 10 gen.

Dal sito possiamo vedere, per esempio, lo stato del nostro sistema di replica, oltre che avere la possibilità di configurare determinati alert via email per avere info sullo stato dei server mongo monitorati.




vi consiglio di abilitare i level del profile con il comando db.setProfilingLevel(2); 

vi consiglio in installare anche munin con:

apt-get install munin-node

in modo da monitorare lo stato della cpu, attenzione munun serve a richiesta quindi bisogna eseguire una accurata gestione dei permessi sui firewall.

Il supporto è favoloso, voi scrivete e loro vi rispondo al volo per qualsiasi cosa.


mercoledì 12 ottobre 2011

MongoDB - Cluster - Sharding and Replica Set


Questa è una configurazione di prova per eseguire dei test sulle possibilità di Cluster con Treplica Set e e bilanciamento del carico con MongoDB (Sharding), il test viene eseguito su una macchina sola, in realtà ogni server mongo deve essere residente su una macchina separata

  •  creo le cartelle per i vari db


/data/r1
/data/r2
/data/r3

/data/r11
/data/r12
/data/r13

/data/cfg1
/data/cfg2

  • configuro ed eseguo i due blocchi di replica (2 blocchi da 3 server)


./mongod --replSet replica1 --dbpath /data/r1 --port 20001 --rest 
./mongod --replSet replica1 --dbpath /data/r2 --port 20002 --rest
./mongod --replSet replica1 --dbpath /data/r3 --port 20003 --rest

./mongod --replSet replica11 --dbpath /data/r11 --port 20011 --rest 
./mongod --replSet replica11 --dbpath /data/r12 --port 20012 --rest
./mongod --replSet replica11 --dbpath /data/r13 --port 20013 --rest

nota: per ogni server è possibile avere l'esecuzione in background e il logging su file aggiungendo --fork --logpath /mongodb/log/<nome_del_file>.log --logappend 
  • eseguo la configurazione per agganciare i server replica.
./mongo localhost:20001

config = {
"_id" : "replica1",
"members" : [
{
"_id" : 1,
"host" : "localhost:20001"
},
{
"_id" : 2,
"host" : "localhost:20002"
},
{
"_id" : 3,
"host" : "localhost:20003"
}
]
}

rs.initiate(config);

----

./mongo localhost:20011

config = {
"_id" : "replica11",
"members" : [
{
"_id" : 1,
"host" : "localhost:20011"
},
{
"_id" : 2,
"host" : "localhost:20012"
},
{
"_id" : 3,
"host" : "localhost:20013"
}
]
}

rs.initiate(config);

----


è possibile accedere alla parte di info via web (opzione --rest) su http://192.168.0.75:21001/ e http://192.168.0.75:21011/

  •  server cfg

./mongod --configsvr --dbpath /data/cfg1 --port 20050 --rest

da qui l'interfaccia web:

http://192.168.0.75:21050/


./mongod --configsvr --dbpath /data/cfg2 --port 20060 --rest

  • Mongo finali

 due mongod per accedere con i client

 ./mongos --configdb localhost:20060 --port 20100 
 ./mongos --configdb localhost:20050 --port 20101 

  • Configurazione Sharding

Collego al mogos finale (che rappresentano la punta del mio sistema)

./mongo localhost:20100
use admin
db.runCommand( { addshard : "replica1/localhost:20001,localhost:20002,localhost:20003" } );
db.runCommand( { addshard : "replica11/localhost:20011,localhost:20012,localhost:20013" } );
  
db.runCommand( { listshards : 1 } );

 a questo punto lo shard su replica è configurato

Primo test, se mi collego al ./mongo localhost:20100 ed eseguo db.runCommand( { listshards : 1 } ); ottengo le configurazioni uguali quindi le info sono propagate a tutto il cluster

------

- a questo punto il client a cui devo accedere sono localhost:20100 e localhost:20101 che sono due erogazioni che dovrebbero essere gestite automaticamente dal driver della mia app.

- il parametro --rest serve ad abilitare l'interfaccia rest del browser. Ogni server è raggiungibile da ip:<porta+1000> es se il server è su localhost:20003 la sua parte web è su http://localhost:21003
  • Test di propagazione
- Collego con una piccola app in java al mongos 20100.
- Carico su un db qualche milione di riga, il cluster propaga e sparpaglia i db interi creati su un ramo di replica e l'altro (replica1 e replica11).
  •  Shard del singolo db: 
./mongo localhost:20100
use admin
db.runCommand( { enablesharding : "freedb" } );
  • Shard di una collection
eseguo uno shard della collection

db.runCommand( { shardcollection : "freedb.disc" , key : { filename : 1 } } );


Dopo diversi db creati e milioni di righe inserite trovo con un ramo di shard corposo e uno quasi libero con soli con 2 db, questo è il risultato dell' autobalancer che appunto bilancia il carico.

  • Consistenza

Caduta di una macchina di replica:

ecco che mi cade un mongo del ramo  localhost:20002 (2), le repliche tengono senza problemi, 
la macchina si è demolita... (elimino il contenuto della cartella /data/r2).
dall'interfaccia web vedo che il server va in recovery: 
localhost:20002 2 RECOVERING initial sync need a member to be primary or secondary to do our initial sync 0:0
poi 
localhost:20002 2 RECOVERING initial sync cloning db: freedb21
etc.

Caduta di due macchina di replica:
butto giù le macchine localhost:20001 e localhost:20002
lancio la mia app, mentre sta girando la app si blocca (forse messa in attesa da driver), il ramo di replica localhost:20003 sembra bloccato, fermo la app.. nulla da fare.
rifaccio ripartire il server 20001, finalmente il 20003 si elegge primary e la app riprende le sue insert, quindi se cadono due macchine sul ramo è possibile che tutto si blocchi e rappresenta la criticità del cluster.

soluzione: creare un server arbiter che aiuti la elezione del master: 
http://tebros.com/2010/11/mongodb-arbiters-with-only-two-replicas/
http://www.mongodb.org/display/DOCS/Upgrading+to+Replica+Sets#UpgradingtoReplicaSets-AddingAnArbiter

mkdir /data/arb1
./mongod --rest --replSet replica1 --dbpath /data/arb1 --port 20005

poi.. cerco chi è il primary all'interno della replica1 dall'interfaccia web http://192.168.0.73:21001/_replSet è il localhost:20003

mongo localhost:20003
use admin
rs.addArb("localhost:20005");
rs.status();

a questo punto dall'interfaccia web http://192.168.0.73:21001/_replSet il server arbitrario è online.

..... il server localhost:20002 va in errore..... :  RECOVERING error RS102 too stale to catch up

http://www.mongodb.org/display/DOCS/Resyncing+a+Very+Stale+Replica+Set+Member

Elimino tutto il contenuto della cartella del cluster 20002  - rm -rf /data/r2/* rifaccio ripartire il server 20002 e riparte di resync

ok, a questo punto le conf sono le seguenti:

localhost:20001 - PRIMARY
localhost:20002 - SECONDARY
localhost:20003 - SECONDARY
localhost:20005 - ARBITER

proseguo con il test per verificare il funzionamento dell'ARBITER.
interrompo i server 20002 e 20001.
..no nulla da fare il server 20003 non viene eletto PRIMARY.. 
..neanche tentando di forzare il server 20003  a PRIMARY la cosa non funziona. 
...quindi per avere una replica consistente è necessario avere almeno 3 server in replica oppure 2 in replica e 1 con arbiter.

-------------

- elimino il contenuto della cartella /data/r2
- inserisco dei dati nel db

./mongo localhost:20100
mongos> use freedb21
switched to db freedb21
mongos> for(i=0;i<100000;i++) db.pippo.insert({"test":"prova","c":i});
mongos> db.pippo.count();
100001
......
......
mongos> db.pippo.count();
5418885

-- db sharding

 ./mongo localhost:20101
MongoDB shell version: 2.0.0
connecting to: localhost:20101/test
mongos> use admin
switched to db admin
mongos> db.runCommand( { enablesharding : "freedb21" } );
{ "ok" : 1 }

- il ramo /data/r2 non ricrea i vari file, devo fermare e far ripartire il server r2, a questo punto il server si sincronizza con tutti i rami della sua replica.

--------









lunedì 5 settembre 2011

Jetty - Hot Deploy e Reload

per eseguire un reload della singola app è necessario eseguire un

touch /etc/jetty/context/configurazione-webapp.xml


oppure inserire al volo una nuova conf.xml e jetty esegue l'Hot deploy senza bisogno del restart del service.




[grazie a Fabrizio]

martedì 30 agosto 2011

Kill Postgres Connection


select procpid from pg_stat_activity where datname='<dbname>';


from bash: kill <procpid>

mercoledì 24 agosto 2011

MongoDB - Backup e Restore


come eseguire un backup ed un restore di un intero db.

dalla console di root

./mongodump

viene creata la cartella /dump/* contenente i db in formato binario

per eseguire il restore:

./mongorestore -v /dump/<nome_db>

[via]

lunedì 22 agosto 2011

Htc Desire S - problema con la tastiera e il Locale

Sono passato dall'HTC Hero all'HTC Desire S, comprato online su Expansys l'unica pecca è che non era presente la tastiera Italiano (Italia). Tra i foum trovo questo programma sul market che aggiunge i locali al piccolo android.

MoreLocale 2

venerdì 20 maggio 2011

linux - conteggio file via bash

conteggio dei file con la bash di linux in modo ricorsivo.


find . | wc -l

[via]

mercoledì 27 aprile 2011

java.lang.OutOfMemoryError: Java heap space


Sempre con il mio programma ciccioso arriva l'errore:

 "Exception in thread "main" java.lang.OutOfMemoryError: Java heap space" 

quindi cambio le impostazione del heap space

java -Xms<initial heap size> -Xmx<maximum heap size>

tipo:
java -Xms512m -Xmx512m

default:
java -Xms32m -Xmx128m



java.lang.OutOfMemoryError: GC overhead limit exceeded

facendo girare una app in java molto pesante mi appare il seguente errore causa da un sovradosaggio del garbage collection:


java.lang.OutOfMemoryError: GC overhead limit exceeded




per evitare basta aggiungere l'opzione -XX:-UseGCOverheadLimit alla riga di esecuzione del nostro .jar in modo da inibire il controllo del overhead del GC.

La spiegazione qui





giovedì 21 aprile 2011

linux - Unrar file multipli

file-part1.rar
file-part2.rar
file-part3.rar


find -type f -name '*.rar' -exec unrar x {} \;

[via basic-linux.bauani.org]

mercoledì 30 marzo 2011

postgresql : eseguire una query da console

..mai che mi ricordo questo comodissimo comando da console

psql <nomedb> -c "select * from..." > file.txt

oppure
<nomedb> -c "update..."

martedì 8 marzo 2011

keypad disable on Ubuntu?

basta premere shift + Bloc Num per abilitare/disabilitare la tastiera

venerdì 3 dicembre 2010

Linux HostName

si, l'host name della macchina è orrendo.

modificarlo da /etc/hostname

ricordarsi di aggiungerlo anche a /etc/hosts
127.0.0.1 <nome_inserito>

altrimenti apache e jetty danno in testa!!!

mercoledì 17 novembre 2010

jetty - link simbolici

problemi con i link simbolici? per jetty bisogna abilitarli, sono disabilitati per motivi di sicurezza:

per abilitarli:

1 andare in <jett.home>/etc/webdefault.xml


<servlet>
...
    <init-param>
      <param-name>aliases</param-name>          
      <param-value>true</param-value>
    </init-param>
...
</servlet>

e verificare per tutti context: /<jetty.home>/etc/contexts/*

 <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set>

martedì 16 novembre 2010

Apache proxy dei file statici

per eseguire un proxy le risorse statiche servendole direttamente da apache.

ProxyPass /static/ !
ricordare di aggiungere il DocumentRoot altrimenti non sa dove prenderli

es:

<VirtualHost *>
     DocumentRoot /usr/local/customers/<nomesito>/

    ServerName www.<nomesito>.it

    ServerAlias noemsi.it

        RewriteEngine On
        RewriteCond %{HTTP_HOST} !www.<nomesito>.it
        RewriteRule ^(.*)$ http://www.<nomesito>.it$1 [R=301,L]

        <Proxy *>
        Order deny,allow
        Allow from all
        </Proxy>

        ProxyPreserveHost On
        ProxyPass /static !
        ProxyPass / http://www.<nomesitointerno>:8080/
        ProxyPassReverse / http://www.<nomesitointerno>.it:8080/


        ErrorLog /usr/local/customers/logs/emeroteca_error_logs
        CustomLog /usr/local/customers/logs/emeroteca_access_logs combined


</VirtualHost>

giovedì 4 novembre 2010

postgresql : database and table size via sql

- questa query può essere utile per eseguire un monitor dello spazio su disco dei db/tabelle.

psql

postgres=# select * from pg_size_pretty(pg_database_size('nomedeldb'));


pg_size_pretty
----------------
1345 MB
(1 row)


size delle tabelle:
SELECT nspname || '.' || relname AS "relation", pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size" FROM pg_class C LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace) WHERE nspname NOT IN ('pg_catalog', 'information_schema') AND C.relkind <> 'i' AND nspname !~ '^pg_toast' ORDER BY pg_total_relation_size(C.oid) DESC;
SELECT relname, (relpages * 8) / 1024 AS size_mb FROM pg_class ORDER BY relpages DESC;