Tips & Tricks – Come rimuovere MySQL

In questo post segnaliamo un piccolo trucchetto che ho trovato, usato con successo e che consiglio nella eventualità si debba fare un pò di pulizie. Nel nostro caso si tratta di un sistema per eseguire le pulizie di una installazione MySQL su di un sistema Ubuntu.

In che consiste?

Su windows le cose sono abbastanza semplici. Basta disinstallare l’applicativo tramite l’apposita procedura. Su Linux la faccenda è un tantinello più complicata. Vediamo come rimediare.

Consultanto il seguente articolo di AskUbuntu.com, ho trovato queste semplici e poche righe di codice, da lanciare via terminal, per eseguire delle vere e proprie pulizie su server, che da sfogo alla nostra sindrome della filippina

Andiamo in dettaglio:

sudo -i
service mysql stop
killall -KILL mysql mysqld_safe mysqld
apt-get --yes purge mysql-server mysql-client
apt-get --yes autoremove --purge
apt-get autoclean
deluser --remove-home mysql
delgroup mysql
rm -rf /etc/apparmor.d/abstractions/mysql /etc/apparmor.d/cache/usr.sbin.mysqld /etc/mysql /var/lib/mysql /var/log/mysql* /var/log/upstart/mysql.log* /var/run/mysqld
updatedb
exit

Cerchiamo di spiegare, con parole semplici, in che consiste per dare indicazioni a chi, non è espertissimo su Ubuntu Linux, in modo da non farlo andare alla cieca.

sudo -i -- Ci colleghiamo come Root
service mysql stop -- Fermiamo il servizio MySQL
killall -KILL mysql mysqld_safe mysqld -- Eseguiamo il kill dei vari processi coinvolti

Semplicemente blocchiamo MySQL.

apt-get --yes purge mysql-server mysql-client
apt-get --yes autoremove --purge
apt-get autoclean

Queste tre istruzioni rimuovono l’installazione di MySQL e …. fanno letteralmente un pò di pulizie sulle installazioni stesse, eliminando pacchetti e dipendenze non più necessarie.

deluser --remove-home mysql
delgroup mysql
rm -rf /etc/apparmor.d/abstractions/mysql /etc/apparmor.d/cache/usr.sbin.mysqld /etc/mysql /var/lib/mysql /var/log/mysql* /var/log/upstart/mysql.log* /var/run/mysqld
updatedb
exit

Questa parte di istruzioni elimina l’utente ed il gruppo mysql. Quindi esegue le pulizie sulla componente apparmor (rimando al link per le spiegazioni su questa componente). Quindi esce dalla modalità Root.

L’articolo citato fornisce anche indicazioni per pulire i file di log e le history, in modo da togliere tutte le tracce di MySQL.

Conclusioni

Abbiamo adesso a disposizione un metodo per ripulire il nostro server, nella eventualità di dover ripulire un pò. Nei prossimi post cercheremo di fornire ulteriori Tips che ci diano una mano.

Nel caso delle installazioni errate

JIRA CORE – proseguiamo la prova su strada

In questo post andremo a proseguire la prova su strada. Passiamo a visionare l’installazione web.

Dove eravamo rimasti

Eravamo rimasti alla pagina iniziale della installazione web, come mostrato nella seguente immagine:

A questo punto, possiamo scegliere due possibili opzioni:

• La prima consiste nel lasciare al setup di fare tutto, fornendo solo alcuni semplici parametri e le indicazioni per staccare la licenza.
• La seconda consiste nel installare manualmente (opzione che andremo a scegliere 🙂 )

Il motivo della scelta è che in questo post voglio spiegare alcuni punti e, se lasciamo l’installazione fare tutto, allora non riesco a mostrarle 😀

Una piccola precisazione

Prima di procedere, abbiamo installato il driver MySQL sul JIRA al termine della installazione.Prima di procedere si è reso necessario un riavvio del servizio. Tutte le istruzioni sono presenti in questa pagina della documentazione di JIRA. Occorre riportare nella <JIRA_HOME>/libs il driver.

Una volta installato, per eseguire il restart del servizio, collegandosi come root, eseguire i comandi stop-jira.sh e start-jira.sh presenti nella <JIRA_HOME>/bin. Se non viene fatto, il driver non sarà disponibile.

Quindi procedere con la creazione del database vero e proprio, usando i seguenti comandi:

• CREATE USER ‘<USERNAME>’@'<JIRA_SERVER_HOSTNAME>’ IDENTIFIED BY ‘<PASSWORD>’;
• CREATE DATABASE jiradb CHARACTER SET utf8 COLLATE utf8_bin;
• GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,ALTER,INDEX on <JIRADB>.* TO ‘<USERNAME>’@'<JIRA_SERVER_HOSTNAME>’ IDENTIFIED BY ‘<PASSWORD>’;
  flush privileges;

come potete vedere nella pagina che ho indicato prima :-).

Proseguiamo

Andiamo quindi avanti con il setup. Il primo passo che viene richiesto è quello di scegliere il database. Come abbiamo già scritto, scegliamo MySQL e forniamo tutti i parametri per la connessione.

La pagina ci consente di poter eseguire il test di configurazione, verificando se abbiamo inserito tutti i parametri corretti. Quindi procediamo con la fase di installazione, dove sarà creata l’intera struttura di tutte le tabelle. Questa operazione richiede del tempo. Lasciamo che lavori senza alcuna fretta e attendiamo che si concluda :-).

Al termine, ci sarà proposta la fase successiva, come mostrato dalla figura successiva:

Son richiesti i seguenti parametri:

• Il titolo del JIRA CORE: viene richiesto che titolo mostrare quando accediamo al nostro JIRA;
• Modalità di accesso:
  • Pubblico: Gli utenti si possono registrare in autonomia
  • Privato: Solo gli amministratori possono creare nuovi utenti
• Definire la Base Url. Si tratta della URL di base che sarà utilizzata per la gestione del nostro JIRA.

Nella fase successiva viene richiesta la Licence Key. Possiamo, in automagico, ricavarla usando il link generate a JIRA Trial licence, come mostrato dalla figura successiva:

che ci reindirizza al portale my.atlassian.com:

attraverso il quale ricavare subito, sfruttando le nostre credenziali, la licenza di uso:

e quindi riportarla subita nel nostro server e procedere nelle ultime fasi di installazione.

Si passa quindi alla generazione della utenza di amministrazione, molto importante. Si tratta di una utenza attraverso la quale riusciremo ad eseguire l’amministrazione dell’intero JIRA. Come mostrato dalla seguente immagine:

specifichiamo tutti i parametri e andiamo a generare la nostra utenza.

Viene quindi chiesto di specificare un avatar. Questo rimarca molto l’aspetto social di JIRA e dei prodotti Atlassian. Come potete vedere, viene specificato l’avatar dell’utente del portale my.atlassian.com.

Quindi, viene richiesto di settare i parametri per gestire la notifica delle email.

Come possiamo vedere dalla immagine, vediamo che viene suggerito di eseguire dopo questa operazione. Suggerisco di eseguirla in una fase successiva. Quindi passiamo a settare il linguaggio che sarà utilizzato su JIRA, come mostrato nella seguente immagine.

Eseguita tale selezione, l’installazione è formalmente terminata e si passa ad una fase di quick tour del prodotto, dove sono spiegate alcune informazioni. Salteremo queste e procederemo oltre.

Fatto ciò, possiamo subito iniziare. Dato che si tratta della prima installazione, viene proposto di creare il primo progetto. Anche in questo caso, possiamo eseguire l’operazione in una fase successiva, come mostrato nella seguente immagine:

Fatto ciò, abbiamo la nostra installazione di JIRA. La Dashboard viene proposta e possiamo iniziare nelle fasi successive:

Conclusioni

Terminiamo qui questo post, chiudendo l’installazione. Proseguiremo nel prossimo post con la prova su strada, verificando le funzionalità, confrontandole con le precedenti versioni e cercando di capire come si comporta questa nuova versione 7 🙂

Visualizziamo numeri

In questo post sarà mostrato come poter utilizzare Confluence per realizzare delle semplici statistiche. Si tratta di un semplice esempio di uso dedicato alla realizzazione di dashboard, che possono sempre aiutarci nel nostro lavoro.

Di cosa abbiamo bisogno?

Quello di cui abbiamo bisogno è:

• Confluence (versione cloud)
• SQL Play
• Database MySql, per fare tutte le prove di cui abbiamo bisogno. Per tutte le nostre prove, utilizzeremo db4free, un sito che gratuitamente mette a disposizione database mysql di test, attraverso eseguire dei test.

Andiamo in dettaglio

In questo post andremo a vedere un semplice esempio di come visualizzare alcune informazioni. IN questo caso supponiamo di andare a visualizzare delle semplici statistiche sui miei consumi di benzina 🙂

A tale scopo, ho creato un semplice DB su db4free, dove ho riportato alcuni semplici dati.

Sfruttando le potenzialità dell’addon SQL Play, ho creato il contesto verso tale database, quindi ho creato la query per visualizzare i dati.

A questo punto creiamo la pagina di prova 🙂

Ovviamente si tratta di dati di esempio. 🙂

Conclusioni

Abbiamo visto come inserire delle semplici statistiche da un database remoto. Possiamo a questo punto creare delle dashboard che, leggendo le informazioni da un db remoto, visualizzano i risultati direttamente sulle pagine di Confluence.

Il viaggio continua

Continuiamo in questo post quanto iniziato nel precedente, dove abbiamo iniziato a esplorare l’oscuro arcano delle tabelle di Confluence. Andiamo avanti ed iniziamo ad entrare meglio nelle varie tabelle.

Prendendo spunto dal data model di Confluence, andiamo ad esaminare alcune delle tabelle dello schema.

Autenticazione ed utenti

Per gestire l’autenticazione, sono utilizzate le seguenti tabelle:

• cwd_user
• cwd_group
• cwd_membership

Mappano rispettivamente gli utenti e i gruppi di appartenenza. La tabella cwd_membership fornisce l’associazione tra utenti e gruppi. . Qualora Confluence sia collegato ad un LDAP, le informazioni in queste tabelle sono aggiornate costantemente e la gestione della password viene affidata al sistema LDAP. Abbiamo visto un esempio di come andare a referenziare queste tabelle su questo post.

Spaces

Le informazioni sugli space sono relegate alla omonima tabella Space. Questa viene referenziata anche sulle altre tabelle, per indicare l’appartenenza dei contenuti.

Contenuti

I contenuti sono riportati nelle seguenti tabelle:

• Content – Referenzia diverse informazioni, distinte in base al campo CONTENTTYPE. In particolare, in questa tabella sono presenti sia le informazioni delle varie pagine, che metadati dell’utente e degli space. Nel caso delle pagine, sono presenti TUTTE le versioni della pagina. Attraverso questa tabella Confluence riesce a fornire le differenze tra pagine.
• Bodycontent – Referenzia il contenuto delle pagine. Queste sono riportati con i vari TAG usati per definirire formati ed altro.
• Content_label – Referenzia le etichette che sono agganciati ai vari contenuti, distinti in base al campo LABELABLETYPE. 

Permissions

Le permission sono sparse su diverse tabelle:

• Spacepermissions – Referenzia le permission che sono state assegnate ad uno specifico SPACE. Sono riportate sia le permission assegnate a GRUPPI che a singoli utenti. Nel caso dei singoli utenti, prestare attenzione a come sono codificati gli utenti stessi. Fare rifermento al precedente post per vedere come referenziare correttamente il tutto
• Content_perm_set – Referenzia quale pagina dispone di una restrizione. Il dettaglio è riportato nella tabella successiva.
• Content_perm – Da il dettaglio delle restrizioni della pagina referenziata nella tabella precedente, indicando quali utenti/gruppi sono soggetti alla restrizione.

Attachments

Gli attachments sono gestiti attraverso queste tabelle

• attachments – Referenzia i metadati che sono agganciati ai dati.
• attachmentdata – Referenzia gli allegati veri e propri, nel caso in cui la configurazione di Confluence preveda che gli allegati siano riportati su DB e non su File System.

Conclusioni

In questo post viene mostrato come sono organizzati i dati. Nei prossimi post cercheremo di fornire una ulteriore spiegazione di come sono collegate le informazioni e di come referenziarle.

JIRA e le sue tabelle

In questo post, proseguiamo quanto iniziato su questo post, dove abbiamo fatto una breve panoramica delle tabelle di Confluence.

In questo caso, proviamo ad eseguire la stessa operazione presentata nel post precedente, ma facendo riferimento alle tabelle di JIRA. La seguente immagine riassume alcune delle tabelle di JIRA. Si rimanda alla sezione Reference per tutte le indicazioni sul caso.

Precauzioni

Si ribadiscono le stesse identiche precauzioni che sono state indicate nel precedente post. Fate sempre un backup dei dati, prima di procedere con qualsiasi operazione. In questo modo potete essere sicuri di poter operare in tutta sicurezza.

Iniziamo 🙂

Cerchiamo di impostare un avatar di default differente da quello preimpostato. Partiamo da questa situazione:

Le tabelle che andiamo a referenziate sono le seguenti:

• cwd_user – Tabella contenente le informazioni degli utenti
• avatar – contenente gli avatar standard
• propertyentry – contenente le associazioni da utente ed avatar utilizzato
• propertynumber – contenente l’associazione con l’avatar collegato all’utente

Procediamo con la modifica

Aggiungiamo il nuovo avatar. Il file va caricato nella directory:

<Install-Dir>Atlassian-JiraWEBINFClassesAvatar

Supponiamo di utilizzare sempre l’icona del pinguino 🙂

Punto di attenzione. A differenza di Confluence, JIRA ha la necessità di avere anche una seconda icona, dimensione 24×24, la metà rispetto alla dimensione dell’avatar che si inserisce, ovvero 48×48, che viene referenziato e mostrato in alto a destra. Predisporre quindi un secondo avatar, nome pari a small_<nome_del_file_nuovo_avatar>.png e memorizzarlo nella stessa directory.

Quindi aggiungiamo un nuovo record, alla tabella avatar, con le indicazioni dell’icona nuova

Dalla tabella cwd_user, identifichiamo l’utente in questione:

Dalla propertyentry ci ricaviamo l’ID per determinare la proprietà da andare a modificare, cercando per ENTITY_ID = ID USER e PROPERTY_KEY = ‘user.avatar.id’:

Quindi dalla propertynumber, ci ricaviamo l’ID dell’avatar utilizzato.

Inseriamo, nel campo propertyvalue, l’ID del nuovo avatar di default, e questo è il risultato:

Conclusioni

Con questo sistema riusciamo ad impostare il nuovo avatar di default in maniera semplice. Questo ci consente di poter eseguire una semplice modifica alla installazione, sostituendo gli avatar in modo semplice.

Se si vuole aggiungere un avatar non di default?

Fattibile, ma occorre agire da tutt’altra parte. In questo caso si dovrebbe memorizzare il file del nuovo avatar in altra directory, ovvero:

<JIRA-Home-dir>dataavatars

e si memorizzano in vari formati, principalmente il formato 48×48 ed il formato 24×24, che servono principalmente per tutte le funzionalità. La configurazione delle tabelle è la medesima. Il nome del file, come per il precedente esempio, deve essere preceduto dal nuovo ID assegnato alla tabella Avatar. Nei prossimi post vedremo altre informazioni sulle tabelle di JIRA.

Scaviamo in profondità

In questo post andremo a vedere, con alcuni esempi, come possiamo accedere ai dati di Confluence e JIRA, lavorando direttamente su DB. In particolare vedremo alcuni esempi di come sono memorizzate le informazioni. In figura vediamo lo schema delle tabelle di Confluence.

Perché accedere ai dati?

Prima di iniziare ad esplorare le tabelle dei due sistemi, conviene porsi una domanda fondamentale: Perché dobbiamo accedere direttamente ai dati del DB? Quale è la necessità?

Uno dei motivi più importanti è sicuramente quello di dover accedere ad informazioni a cui non si avrebbe altrimenti accesso, oppure il dover eseguire una operazione massiva. Questo perché non sempre è possibile eseguire una operazione su di una grossa mole di dati, in quanto Confluence/JIRA non la consentono, come ribadito in altri post di questo blog. Fino a quando non saranno disponibili delle funzionalità di un certo tipo, occorre dover agire direttamente da DB. In aggiunta, queste informazioni sono sicuramente utili a coloro che vogliono sviluppare addon per i prodotti Atlassian 🙂

Precauzioni

Prima di agire, occorre sempre che siano prese delle semplici precauzioni. Il motivo mi sembra abbastanza semplice: Quando si lavora direttamente su DB, è abbastanza facile arrecare danni. Di conseguenza, sempre meglio avere un backup dei dati/tabelle/DB intero prima di procedere con le modifiche.

Il mio consiglio è sempre quello di avere a disposizione un backup del DB completo + una copia delle tabelle su cui si agisce, prima di procedere con qualsiasi operazione.

Un primo esempio

Supponiamo che si voglia modificare gli avatar standard, con un avatar differente (i motivi possono essere qualsiasi: Marketing aziendale,  impostare un avatar di default più carino, etc).

Al momento, solo gli utenti possono modificare il proprio avatar. A livello di amministrazione, non è possibile eseguire tale operazione. La precedente immagine mostra dove è possibile eseguire tale operazione. Adesso vediamo come è possibile aggirare tale limitazione, semplicemente andando a lavorare su DB.

In prima battuta esaminiamo le tabelle dove sono contenute le informazioni delle utenze. In particolare faremo riferimento a:

• cwd_user – Tabella contenente le informazioni degli utenti che sono stati configurati in Confluence.
• cwd_group – Tabella contenente le informazioni dei gruppi definiti su Confluence.
• os_propertyentry – Tabella contenente anche le informazioni degli avatar.
• user_mapping – Tabella contenente la corrispondenza uid – nome utente.

La tabella che ci interessa in particolare è l’ultima. Dobbiamo andare a cercare le informazioni degli avatar, utilizzando questa query:

Come si vede dalla precedente immagine, quello che dobbiamo andare a cercare è il campo String_val. In questo campo è presente la localizzazione dell’avatar. In questo caso ho assegnato un avatar di default. 🙂 Nel campo Entity_name abbiamo la userid. Come possiamo vedere è abbastanza ….. criptata. Come facciamo a decodificarla? Il giro è il seguente:

• Dalla tabella os_propertyentry abbiamo le indicazioni del path della immagine
• Dalla tabella user_mapping abbiamo le indicazioni dell’uid dell’utente
• Dalla tabella cwd_user abbiamo il nome dell’utente.

Le seguenti immagini chiariscono il tutto: Dall’ID identifichiamo l’utente

Di conseguenza, per modificare l’avatar dell’utente admin (in questo caso), possiamo semplicemente modificare il path e andare ad assegnarne uno nuovo. Supponiamo di creare una sottodirectory nel path utilizzato da Confluence per gestire gli avatar di default, ovvero:

<Install_dir_Confluence>confluenceimagesiconsprofilepic

supponiamo di chiamarla Demoprofile e di memorizzare il seguente avatar:

Eseguire il restart del servizio Confluence e, come per magia, il risultato sarà il seguente:

Conclusioni

Abbiamo visto un esempio di come si può modificare il database per modificare gli avatar degli utenti di Confluence. Questo esempio può essere utilizzato anche per le installazioni per cui gli utenti sono presi da LDAP e non sono solo utenti locali di Confluence.  Nei prossimi post vedremo altri esempi di come si può accedere ai dati e …. vedere altre informazioni.