Archives For Database

Una domanda apparentemente complessa che merita una risposta semplice, per cercare di incontrare quanto più pubblico alle prime armi possibile. Ho risposto in separata sede, mi piace però condividere pubblicamente quella che secondo me può essere una buona scaletta per far muovere i primi passi al tuo nuovo sito web basato su WordPress (a prescindere che si tratti di blog personale o altro tipo di idea). Ti invito a dire la tua nell’area commenti, inserendo nuovi punti esclusi dalla mia personale lista, ma evidentemente non per questo non meritevoli di menzione. Cominciamo?

WordPress: ShortPixel Image Optimizer 8

#1: Creare un account amministrativo diverso

In realtà di questo argomento ne abbiamo già parlato, forse lo ricorderai. Mi cito copiando e incollando un passaggio fondamentale di questo diverso articolo:

Ciò che intendo è, per esempio, non utilizzare l’account amministrativo di default (che va quanto prima degradato a semplice utente, se non addirittura eliminato), in favore di un nuovo account da te appositamente realizzato, amministrativo, con username non facilmente indovinabile e con una password complessa (parleremo anche di password robuste quanto prima, ma ti porto a questa vignetta, che tanto spiega in merito). Non utilizzare la stessa password che hai già usato in passato per altri servizi. Fatti aiutare da un buon password manager se ti serve.

Il consiglio rimane lo stesso identico: elimina quanto prima l’account “admin” creato automaticamente da WordPress, non prima di averne creato uno diverso con gli stessi poteri, il quale dovrà avere username differente, più complesso, così come la password, che dovrà inoltre essere dedicata e non condivisa con altri servizi che sfrutti su internet. Posso comprendere che questa sia per te una scocciatura, ma ringrazierai quel giorno in cui qualcuno scoprirà (per errore altrui) qualche tua coppia di credenziali (ne parlo nell’articolo Firefox Monitor ti avvisa in caso di furto credenziali) e le userà anche per appropriarsi del tuo sito web.

Fondamentale e oggi ormai dato per scontato è il doppio passaggio di autenticazione. In passato ti ho parlato di Authy, ho poi virato verso un diverso metodo di verifica autenticazione, te ne ho parlato nell’articolo WordPress: migrazione da Authy OneTouch a Duo.

#2: Creare gli account aggiuntivi per editor e collaboratori

Che, a voler essere puntigliosi, potrebbero bastare anche alla tua quotidianità. Le operazioni da eseguire tramite l’account amministrativo sono relativamente poche se hai ormai configurato al meglio il tuo sito WordPress, per questo motivo potresti pensare di creare per te un account “Editor” in grado di scrivere, modificare o cancellare qualsivoglia contenuto pubblicato (o in attesa di pubblicazione), lasciando all’amministratore il compito della manutenzione del software, l’installazione di qualche plugin e poco più. Occhio a ciò che permetti ai tuoi collaboratori, i ruoli di WordPress sono pochi e ben spiegati nel documento Roles and Capabilities sul Codex.

Per aggiungerne di nuovi, io ho utilizzato (e utilizzo tutt’oggi) il plugin Members, fantastico per poter creare nuovi ruoli e modificarne i permessi scendendo molto nel dettaglio (puoi permettere o negare singole azioni, la granularità è davvero ottima):

Members
Members
Developer: Justin Tadlock
Price: Free

#3: Occhio al fuso orario

Sembra una banalità ma non lo è, il fuso orario di WordPress (Timezone nelle installazioni in inglese, come la mia) è fondamentale quando programmi la pubblicazione di un articolo, non vorrai mica rischiare di tirare fuori dei pezzi a orari tutt’altro che in accordo con la tua linea editoriale, vero? :-)

SettingsGeneral (Impostazioni → Generali in italiano) nella tua dashboard amministrativa, quindi seleziona Roma (immagino) nel menu a tendina in corrispondenza del fuso orario:

WordPress: muovere i primi passi post-installazione 1

#4: Permetti la Visibilità ai motori di ricerca

Altro parametro che può passare inosservato ma che è fondamentale se vuoi iniziare a macinare qualche visita oltre quelle che sei solito fare tu per amministrare il sito web o scrivere e pubblicare contenuti. All’interno delle Impostazioni di lettura troverai un’opzione relativa alla Visibilità ai motori di ricerca, ciò che permette a Google e soci di indicizzare i tuoi contenuti e renderli fruibili da chi lancia query tramite i siti web più utilizzati al mondo (i motori di ricerca, per l’appunto).

WordPress: muovere i primi passi post-installazione 2

Assicurati che questa non sia impostata per scoraggiare tale comportamento, configurazione che solitamente si usa durante la preparazione del sito web, che va assolutamente modificata quando questo andrà in produzione e farà il suo debutto sul web.

#5: Configura una corretta struttura Permalink

In breve: Un permalink o collegamento permanente è un tipo di URL che si riferisce ad una specifica informazione, implementato in modo da non cambiare o almeno da rimanere lo stesso per lunghi periodi di tempo. Il termine è spesso impiegato nell’ambito dei blog per indicare il link ad un determinato post.

Continua su it.wikipedia.org/wiki/Permalink

È ciò che condurrà il lettore al tuo articolo negli anni, a prescindere da ciò che succederà, dando stabilità ai risultati di un motore di ricerca, rendendolo ben felice di continuare a servirti e portare al tuo porto nuove visite. È una struttura molto importante, critica per certi versi, è giusto deciderla all’avvio di un tuo nuovo progetto, la puoi configurare da ImpostazioniPermalink. Per questo blog ho scelto ormai tanti anni fa quella basata su anno/mese/giorno e nome dell’articolo, se potessi tornare indietro (cosa che comunque puoi pilotare abbastanza agilmente, con tanta pazienza e qualche giusto aiuto) sceglierei quella basata solo sul nome dell’articolo.

WordPress: muovere i primi passi post-installazione 3

#6: I soli Permalink non risolvono tutto, genera una Sitemap

La Sitemap permette a Google di venire a conoscenza di tutti i collegamenti che un lettore può fruire all’interno del tuo nuovo sito web, generarla e darla in pasto al motore di ricerca toglie carico di lavoro a quest’ultimo, il quale -salvo errori- digerirà immediatamente quanto dato in pasto, generando immediatamente visite a tuo favore (ammesso che l’utente stia cercando ciò che tu metti a disposizione). Per farlo puoi farti dare una mano da uno dei tantissimi (pure troppi) plugin disponibili sul repository ufficiale di WordPress. Io, come tanti altri, utilizzo la funzione integrata all’interno di Yoast, quella che trovi all’interno di SEOFeatures → XML Sitemaps:

Yoast SEO
Yoast SEO
Developer: Team Yoast
Price: Free

WordPress: muovere i primi passi post-installazione 4

#7: Hai attivato Google Analytics?

Restiamo sull’argomento statistiche e corretta gestione da parte dei motori di ricerca. Analytics è lo strumento realizzato da Google per tenere d’occhio le proprie “performance” (che detta così suona un po’ come un film di Rocco, ma non è ciò su cui si fonda il pezzo!), per cercare di costruire una strada di costante miglioramento, seguire i gusti dei lettori (senza dimenticarsi però che l’opera è prima di tutto tua, deve piacere a te), sfoderare l’asso quando serve tirarlo fuori dalla manica.

A tal proposito, ThemeTrust aveva pubblicato un articolo molto ricco e ben realizzato (in inglese) che puoi trovare all’indirizzo themetrust.com/google-analytics-in-wordpress (se vuoi proporre un’alternativa altrettanto valida in italiano sei il benvenuto, lascia un commento a fondo articolo!).

#8: Il backup ragazzo, il backup.

Ripeti con me: creerò e manterrò un backup aggiornato del mio sito web, di ogni suo contenuto e del database. Ora continua a ripeterlo, ma nel frattempo metti in piedi una soluzione di backup del tuo WordPress. Ci sono mille metodi validi, io continuo a operare su due piani diversi, facendo più backup al giorno del database MySQL e un backup quotidiano dei file. Te ne ho già parlato qui, ma ti ripropongo lo specifico passaggio:

Avere una copia di backup aggiornata è fondamentale per evitare di incorrere in possibili disastri (causati da te, dal tuo provider o da qualcuno di completamente estraneo).
Per portare a termine questa operazione esistono decine di plugin, sia gratuiti che a pagamento. Io ho scelto di affidarmi a BackUpWordPress della Human Made.

BackUpWordPress

In conclusione

Di punti ce ne potrebbero essere molti altri, ci si ferma qui per convenienza e per non mettere ulteriore carne sul fuoco, ma sei libero di suggerirne di nuovi, per poterli integrare all’interno di questa lista o per giustificare una nuova pubblicazione dedicata, libero sfogo ai tuoi consigli quindi. Resto a disposizione anche per correggere qualche svista o migliorare qualche punto sopra riportato, un po’ come sempre capita :-)

Buon divertimento!


liberamente ispirato a themetrust.com/do-after-launching-a-wordpress-site

Condividi l'articolo con i tuoi contatti:

Per chi non lo dovesse ancora conoscere, il database places.sqlite è ben descritto (nonostante venga specificato che si tratta di linea introduttiva di massima) in un documento ospitato da MDN, il sito web dedicato agli sviluppatori interessati a capire (e magari mettere mano) al mondo dei programmi Mozilla. Ciò che tu probabilmente ignori (e non c’è niente di male, aggiungerei), è che quel database contiene pezzi fondamentali della tua navigazione quotidiana: dai Segnalibri alla Cronologia, passando per le favicon e gli accessi a ogni sito web (utile per realizzare poi le liste automatiche di siti web più visitati, per fare un esempio). Puoi quindi capire la sua importanza e il fatto che debba essere tutelato e curato.

Firefox: snellire la cronologia pulendola automaticamente

Un database tenuto pulito è più veloce, più reattivo in fase di apertura e consultazione della cronologia, più facile da gestire per Firefox. In alcuni casi (il mio ne è un esempio) si può decidere di non cancellare la cronologia e mantenerla così viva per consultazione futura, ma quando quella consultazione supera un certo numero di giorni di profondità, è possibile che questa non abbia più senso, occupando solo dello spazio su disco fisso e rallentando le prestazioni del browser:

È per questo motivo che ci si può appoggiare a un componente aggiuntivo in grado di svolgere un lavoro di pulizia in maniera automatica, così da andare a snellire sì la Cronologia, ma null’altro in base a quanto specificato dalla nostra configurazione del browser. Io utilizzo da anni un componente aggiuntivo realizzato dal collega di forum Marco “MaK” Bonardo, Expire History By Days, disponibile gratuitamente passando dal sempreverde AMO, aggiornato e perfettamente compatibile con l’era Quantum di Firefox:

Expire history by days
Expire history by days
Developer: Mak
Price: Free

Puoi impostare il numero di giorni di Cronologia da mantenere direttamente nelle opzioni del componente aggiuntivo (io ho scelto 150 giorni di profondità massima, oltre la quale l’addon può cancellare ogni traccia dal database), al resto ci penserà lui.

In alternativa, nel caso in cui tu volessi passare da un diverso componente aggiuntivo, potrei proporti History AutoDelete, altro componente aggiuntivo gratuito che trovi su AMO:

History AutoDelete
History AutoDelete
Developer: Kenny Do
Price: Free

Compatibile anch’esso con Firefox di nuova generazione, utilizza lo stesso principio del componente aggiuntivo di MaK, ma propone qualcosa in più rispetto al primo citato, permettendo di cancellare su richiesta la Cronologia del singolo dominio (un po’ come andare a richiamare il “Dimentica sito web” già integrato in Firefox e nella sua finestra di Cronologia), oltre che impostare un certo numero di giorni da mantenere (oltre i quali fare piazza pulita), tenere traccia delle cancellazioni operate e permettere comportamenti precisi per domini che è possibile specificare manualmente o tramite importazione di liste.

Tu sei solito fare pulizia della tua Cronologia? Fai parte magari del club che tutto pulisce in fase di chiusura browser o preferisci operare per singolo dominio? Parliamone nell’area commenti! Magari salta fuori qualche altro buon suggerimento :-)

Condividi l'articolo con i tuoi contatti:

Ciao. Ti sei ritrovato davanti all’errore “psql: FATAL: no pg_hba.conf entry for host “::1”, user “postgres”, database “servicedesk”,SSL off” mentre cercavi di collegarti via prompt al database del tuo ServiceDesk Plus? Anche io. Poi ho scoperto che si tratta di un errore riconosciuto da documentazione ufficiale, e che ti basta modificare un file di configurazione per poter tornare sulla retta via.

ServiceDesk: Error While connecting postgresDB

Di come collegarti via prompt al database del tuo software di supporto te ne avevo già parlato qui:

ServiceDesk: jespa.log sempre più grande?

Per risolvere il problema che ho riportato in apertura “pillola” devi invece ritoccare il file pg_hba.conf che trovi sotto ManageEngine\ServiceDesk\pgsql\data, andando a togliere il cancelletto di commento in corrispondenza dei valori specificati sotto la riga # IPv6 local connections.

La situazione che dovresti trovare è teoricamente questa:

# IPv6 local connections:
#host all all ::1/128 trust

Tu dovrai trasformarla in questa:

# IPv6 local connections:
host all all ::1/128 trust

Salva il file e riprova a connetterti al database, non dovresti ora riscontrare ostacoli.

È tutto spiegato qui: kbase.servicedeskplusmsp.com/troubleshooting/2014/02/28/error-while-connecting-postgresdb.

Buon lavoro!

×

Pillole

Le pillole sono articoli di veloce lettura dedicati a notizie, script o qualsiasi altra cosa possa essere "divorata e messa in pratica" con poco. Uno spazio del blog riservato ai post "a bruciapelo"!
Condividi l'articolo con i tuoi contatti:

Dando per assodato che tu abbia già letto il vecchio articolo sull’argomento (tutt’oggi valido, quindi leggilo pure se non lo hai già fatto), in questo nuovo articolo voglio proporti ulteriori best practices da adottare per provare a proteggere quanto più possibile il tuo blog, il tuo utente e quindi l’accesso a ore e ore di lavoro che vuoi mantenere pulite e funzionanti online, per garantire la tua presenza nel web.

WordPress e sicurezza: alcune best practices 2

L’articolo dei 5 passaggi fondamentali per la sicurezza di WordPress include note riguardanti la rimozione dell’utente amministrativo predefinito, la verifica e l’aggiornamento dei plugin installati (ma anche di WordPress stesso), il backup dei dati (file modificati e copia del database MySQL completo) e l’utilizzo di un plugin di sicurezza che possa dare maggiori indicazioni verso la direzione desiderata (quella per una protezione quanto più completa possibile). Cosa si può aggiungere oggi alla lista?

Autenticazione a due fattori

Te ne sto parlando fino a sfinirti, i miei articoli dedicati al mondo dell’autenticazione 2-Step hanno ormai lo stesso sapore delle preghiere che la nonna ti costringeva a dire prima di andare a letto, oppure in chiesa quando riusciva a trascinarti là dentro durante la domenica mattina, me ne rendo conto. Eppure, nonostante i gravi bug che saltano ogni ostacolo, l’autenticazione in due passaggi resta uno dei punti fondamentali da sfruttare per la propria protezione. Dove possibile, è sempre bene abilitarla.

Ti ho già parlato di autenticazione 2-Step e WordPress, grazie all’utilizzo del plugin di Authy, mi basta riportarti il vecchio articolo, è valido tutt’oggi:

WordPress e Authy: autenticazione OneTouch

Modifica delle chiavi di sicurezza

Tecnicamente “Salt“. Copio e incollo direttamente da un wp-config.php di base:

Authentication Unique Keys.
Change these to different unique phrases!
You can generate these using the {@link https://api.wordpress.org/secret-key/1.1/ WordPress.org secret-key service}
You can change these at any point in time to invalidate all existing cookies. This will force all users to have to log in again.

e trovi qui un articolo su iThemes.com che meglio spiega di cosa si tratta:

A WordPress salt is a random string of data that hashes the WordPress security keys in the wp-config.php file.
If you open your wp-config.php file, you’ll see the Authentication Unique Keys and Salts section with seven security keys.

Puoi aprire in qualsiasi momento il tuo file wp-config.php e, spostandoti nell’area dedicata alle “Authentication Unique Keys“, selezionarle e sostituirle con quelle generate randomicamente dal tool ufficiale di WordPress che trovi all’indirizzo api.wordpress.org/secret-key/1.1/salt. Caricando nuovamente il file sul tuo spazio FTP, perderai l’accesso alla tua Dashboard e ti verrà richiesto di eseguire nuovamente il login, lo stesso varrà per qualsiasi altra postazione precedentemente collegata alla stessa Dashboard.

Se utilizzi come me un plugin di sicurezza, controlla che questo ti permetta di eseguire più rapidamente questa operazione, come succede per iThemes Security:

WordPress e sicurezza: alcune best practices 1

Meglio se HTTPS

In linea di massima questo sarebbe necessario e dovuto per blog (siti web più in generale) che propongono form di login, ma è comunque bene tenere conto che sarebbe meglio passare da HTTP a HTTPS pur integrando un certificato di base generato via Let’s Encrypt. Così facendo si crea una connessione criptata tra client e server, più difficile da intercettare e analizzare (ho detto più difficile, non impossibile, prima che qualcuno faccia lo sborone nei commenti). Se vuoi, ti posso proporre un articolo in inglese che ti descrive buoni motivi per passare a HTTPS, altrimenti ti rimando direttamente al mio –di articolo– dove ti spiego come eseguire la migrazione del tuo blog WordPress:

WordPress: passaggio da HTTP a HTTPS (aggiornato)

C’è altro?

Lo chiedo a te, proprietario di un blog e curatore del WordPress alla sua base. Di punti riguardanti la sicurezza del software ideato e inizialmente sviluppato da Matt Mullenweg probabilmente ce ne sono moltissimi altri, si può sempre migliorare il suo hardening, ogni giorno c’è un buon consiglio da seguire e mettere in atto, ma voglio potermi confrontare con te che stai leggendo questo mio ulteriore pezzo sull’argomento, chiedendoti di proporre nuovi punti per un prossimo aggiornamento, o magari precisare qualcosa di già discusso, sai bene che mi fa sempre piacere sviluppare discorsi ben motivati in merito agli articoli pubblicati.

Buon lavoro!


Immagine di copertina Glenn Carstens-Peters on Unsplash
Condividi l'articolo con i tuoi contatti:

Avevamo già parlato di ServiceDesk Plus e tuning qualche tempo fa, quando la piattaforma principale girava su MySQL (se la usavi già da qualche tempo), ormai andato completamente fuori supporto secondo lo sviluppatore del software (è stato richiesto il passaggio a PostgreSQL per continuare a ottenere supporto):

Pulizia e Tuning di ServiceDesk Plus (MySQL)

Cosa cambia dal punto di vista del tuning dell’installazione con PgSQL?

Tuning di ServiceDesk Plus (PostgreSQL)

Nulla a livello di Wrapper Java, almeno rispetto alla precedente volta quando si parlava di modifica per macchine con almeno (o più) di 4 GB di RAM, che è poi lo stesso concetto di base che riguarda l’ulteriore modifica del file di configurazione del Postgres suggerito sempre all’interno della community del prodotto (ServiceDesk, nda).

Ferma il servizio di ServiceDesk prima di continuare ed effettua un backup dei tuoi attuali dati (consigliato uno Snaphost della macchina, se virtuale).

Ti ripropongo ora il passaggio relativo al Wrapper del precedente articolo:

Il file di configurazione del Wrapper Java è quello che trovi in C:\ManageEngine\ServiceDesk\server\default\conf\wrapper.conf, da ritoccare sui due valori suggeriti:

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=128

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=256

a (nel caso della mia macchina con più di 4GB di RAM, occhio quindi alla tua):

# Initial Java Heap Size (in MB)
wrapper.java.initmemory=256

# Maximum Java Heap Size (in MB)
wrapper.java.maxmemory=1024

[…]

Ciò che stavolta cambia è il file di configurazione relativo al database. Sto parlando del postgres_ext.conf che dovresti poter trovare già nella cartella ManageEngine\ServiceDesk\pgsql\data. Probabilmente al suo interno potresti già trovare qualche specifica, per esempio:

wal_level = archive
archive_command = 'IF EXIST archive.bat (archive.bat "%p" "%f")'
archive_mode = on

Ciò che tu devi fare, è semplicemente dare un colpo di invio e aggiungerne qualcuna in più, per includere nuovi parametri entro i quali Postgres può continuare a riservare memoria per sé. Sto parlando di questi:

shared_buffers = 512MB
maintenance_work_mem = 100MB
effective_cache_size = 512MB
work_mem = 12MB

che, rispettivamente:

  • shared_buffers: corrisponde generalmente al 25% della memoria di sistema. Su Windows, 512 MB può essere il valore massimo.
  • maintenance_work_mem: corrisponde circa il 5% della memoria di sistema, ma senza superare mai i 512 MB.
  • effective cache size: si aggira approssimativamente sul 50% della memoria fisica disponibile, ho personalmente continuato a indicare 512 MB anche se avrei potuto tenerlo più alto.
  • work_mem: riporta un valore ragionevole che si attesta tipicamente tra i 4 e i 64 MB.

Il riferimento sulla community di ManageEngine, seppur riferito a SupportCenter, è questo: pitstop.manageengine.com/portal/community/topic/supportcenterplus-optimize-postgresql

Puoi riavviare ora il servizio di ServiceDesk per verificare se la modifica alla configurazione appena operata ha portato i benefici sperati (risposta positiva nel mio caso).


Condividi l'articolo con i tuoi contatti: