ownCloud and NextCloud : maximum file upload size limit (EN version)

After installing and testing this cloud service on a server of mine on internet, I find a noisy problem: when I try uploading a file bigger than 512Mb the cloud service stop uploading.
Considering that a lot of people uses cloud services as backup for pics and videos, I found out this limit really frustating.

I have not found the way to change this limit via web interface, so I do it via console, on the server where ownCloud was installed.

As first thing I verified limits set up in /etc/php5/apach2/php.ini:

1.    upload_max_filesize should be set more than default 512mb: I set to 1024M
2.    post_max_size should be set more than default 512mb: I set to 1024M
3.    upload_tmp_dir must point to a valid read/write access directory: I set to /tmp

Once done, I reloaded apache2 config files, as usual, with service apache2 reload, but the change to upload_max_filesize seems have no effect and ownCloud still refuse to load file bigger than 512mb

So I gave a look to the ownCloud specific .htaccess file, you find it in the root of the owncloud installation dir, on ubuntu system it is at /var/www/owncloud/.htaccess.
You must edit the line php_value upload_max_filesize 512M to the value you set in apache php.ini or smaller. I set both to 1024M and not to 1G couse I found no info on notation usable in the ownCloud documentation. So I kept the original notation.

At https://secure.php.net/manual/en/ini.core.php#ini.post-max-size found info about size notation: 

PHP allows shortcuts for byte values, including K (kilo), M (mega) and G (giga). PHP will do the conversions automatically if you use any of these. Be careful not to exceed the 32 bit signed integer limit (if you’re using 32bit versions) as it will cause your script to fail.

The last problem is that after the modification, in the webclient the uploadable maximum size reported was still 512Mb.

On truth it was false, couse I already uploaded files larger than  512Mb after the modification I reported above.
In any case to solve this problem, again edit .htaccess file on the line php_value post_max_size to the corresponding upload_max_filesize value. Once done also this problem is solved.

Hope this can help anyone who finds 512Mb too small as upload limit.

Perché evitare ARUBA per la gestione DNS.

É un peccato, ma mio malgrado, mi vedo costretto a scrivere questo post, per evitare ad altri di dover incappare nello stesso tipo di problema in cui sono capitato io.
 
SITUAZIONE: Avete il vostro cliente che vi chiede di installargli un server di posta, con tutti i soliti crismi, affinché l’azienda possa affrancarsi dal loro precedente gestore di posta, che li sta, al solito, derubando. Le considerazioni sui costi imposti dalle altre aziende per servizi di posta in locazione le lascio ad un altro post.
 
Voi fate tutto il vostro lavoro:
 
  1. configurate ed installate il vostro hw
  2. installate e configurate il vostro software
  3. testate se a livello locale funziona tutto.

A questo punto vi occupate della visibilità del server su internet e dovrete, per forza di cosa, mettere anche le mani sui record DNS affinché il server sia visibile ed operativo si internet.

 

Create i soliti  domini tipo imap.dominio.it, smtp.dominio.it facendoli puntare all’IP giusto, e tra le cose primarie da fare per un server di posta, dovete configurare i rispettivi record SPF e DKIM; e qui cominciano i guai.

Se avete la gestione del dominio sotto ARUBA, vi accorgerete subito che qualcosa non torna: accedendo al tipo record TXT dal pannello di gestione del DNS, avrete una schermata come questa:
 
 
Non notate nulla di strano? Finché dovete registrare il campo SPF no, è fatto apposta, ma quando devo registrare il campo DKIM ???? Semplicemente, con ARUBA, non lo potete fare. 
 
Per qualche strano, ma sopratutto oscuro, motivo ARUBA ha deciso che l’unico utilizzo che il suo cliente può fare del campo TXT è l’inserimento dei valori per tipo campo SPF.
 
Li ho contattati, credendo in un problema del form, ma no: è proprio così; hanno deciso che il cliente ARUBA può solo inserire quello che vogliono loro, ossia il campo SPF, ma altri record di tipo TXT, e ce ne sono parecchi che uno potrebbe aver necessità di inserire oltre al tipo DKIM, se lo scordano. 
 
La loro soluzione al problema? “Acquisti una machina virtuale così da potersi gestire il server DNS come meglio preferisce“, e chiaramente mi rifilano il link dei loro server virtuali.
 
Ma ti pare che uno per inserire un campo fondamentale in un server di posta, deve impiantarsi un server DNS proprio ?????
 
Questi secondo me, in questo caso, l’hanno fatta fuori dal vaso!!!
 
Per cui: tenete a mente che se dovete utilizzare per qualsivoglia motivo un record TXT nella gestione DNS che non sia il record SPF, lasciate perdere ARUBA.
 
JC
 

Utilizzo di TOR su IP diverso dal primario.

Al giorno d’oggi, può capitare sempre più spesso di aver a disposizione  una connessione con un set di indirizzi pubblici. Che siano quattro o sette, resta il problema, spesso, di come poterli usare se abbiamo una macchina sola. Oggi vi farò vedere come utilizzare un server TOR che utilizzi un indirizzo IP che non sia il primario della macchina. Sto parlando di un ambiente *nux, ma credo che in qualche modo sia possibile anche in windows, ma personalmente non metterei mai alcun tipo di server su una macchina windows, quindi non starò nemmeno a perdere tempo ad immaginare come farlo. 
 
Prendiamo in esempio una situazione: avete la vostra macchina linux che usate come desktop o come server, non importa, e desiderate utilizzare TOR come servuer, indipendentemente se come hidden_service o come relay; quello che non volete è incappare in una situazione come quella riportata in altro post che ho scritto tempo fa a riguarda dell’uso di TOR e l’aver come home banking il servizi di Unicredit. Il post lo trovate qui: http://bulk.jcsh.eu/?p=103 e si intitolava, guarda caso:”Ad Unicredit Web non piace TOR”. 
 
Avendo più indirizzi IP a disposizione il problema è risolvibile, perché quelli di TOR hanno previsto una situazione simile: basteranno un paio di modifiche al file di configurazione torrc ed il gioco sarà fatto. Capiamoci: non sto parlando di una situazione con due schede di rete con due cavi fisici appartenenti a due IP diversi, ma della situazione, ben più comune, per cui abbiamo un cavo ed n IP disponibili. Vale la pena di definire il quadro in cui ci stiamo muovendo: abbiamo una scheda di rete fisica ed, facciamo un esempio, 4 IP pubblici  disponibili.
 
Innanzi tutto dobbiamo sapere che nome logico ha la nostra scheda di rete; ci son diversi modi, ma quello più rapido è aprire la console (da cui faremo tutto) e dare il comando ifconfig. Avremo come risultato qualcosa del genere:

eth0      Link encap:Ethernet  IndirizzoHW 00:0e:a6:ba:ec:80

indirizzo inet:192.168.1.130  Bcast:192.168.1.255  Maschera:255.255.255.0          

indirizzo inet6: fe80::20e:a6ff:feba:ec80/64 Scope:Link          

UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1          

RX packets:24277872 errors:0 dropped:216 overruns:0 frame:0          

TX packets:12679995 errors:0 dropped:0 overruns:0 carrier:0

Byte RX:772240782 (772.2 MB)  Byte TX:1004742354 (1.0 GB)         Interrupt:18lo       

Link encap:Loopback locale           

indirizzo inet:127.0.0.1  Maschera:255.0.0.0          

indirizzo inet6: ::1/128 Scope:Host          

UP LOOPBACK RUNNING  MTU:65536  Metric:1          

RX packets:14854 errors:0 dropped:0 overruns:0 frame:0          

TX packets:14854 errors:0 dropped:0 overruns:0 carrier:0         

Byte RX:1533885 (1.5 MB)  Byte   TX:1533885 (1.5 MB)


La voce eth definisce il nome logico della nostra scheda di rete; lo 0 un contatore che parte da zero e che indica quale sia la scheda di rete se ne abbiamo diverse; aveste sulla vostra macchina due schede di rete, trovereste elencata anche una scheda eth1 e così via. Attenzione, aveste anche cinque schede di rete, ma un solo cavo che vi arriva da internet, il metodo resta sempre questo perché non potete collegare un IP virtuale su una scheda fisica: la scheda fisica o c’è o non c’è!! Nel nostro esempio faremo il caso di avere disponibili gli IP pubblici da 155.100.100.1 al 155.100.100.Quindi cominciamo:

  1. Considerando che sicuramente avete assegnato 155.100.100.1 come indirizzo della scheda fisica, assegnamo il 155.100.100.4 ad una scheda virtuale, che chiameremo eth0:1 quindi nel terminale diamo il comando:  sudo ifconfig eth0:1 155.100.100.4 up
  2. installiamo il necessario per avviare il server TOR sulla nostra macchina, uso i domando apt-get perché i sistemi debian based sono quelli più installati. Quindi eseguiamo, sempre nella nostra shell, sudo apt-get install tor tor-geoipdb torsocks. Questi sono i tre componenti base necessari.
  3. Fermiamo il server TOR, perché ancora non è configurato come ci serve, e quindi diamo il comando sudo service tor stop
  4. Apriamo con l’editor di testo che preferiamo, io uso VI, ma NANO come altri vanno altrettanto bene, il file di configurazione di TOR quindi se usiamo VI diamo il comando sudo vi /etc/tor/torrc
  5. Alla riga 103 togliamo il commento e modifichiamola affinché risulti così: OutboundBindAddress 155.100.100.4 
  6. appena sotto questa riga ne inseriamo una nuova ed aggiungiamo: Address 155.100.100.4
  7. usciamo dal nostro editor confermando la modifica e rilanciamo il servizio che avevamo fermato al punto 3, con il comando sudo service tor start
  8. diamo un comando di lettura del file di configurazione ossia sudo tail -f /var/log/tar

Vedrete diverse cose scorrere sullo schermo, ma quello che deve esserci, affinché possiamo essere certi che TOR stia usando l’IP che diciamo noi, è la seguente riga:

[notice] Now checking whether ORPort 155.100.100.4:9001 and DirPort 155.100.100.4:9030 are reachable… (this may take up to 20 minutes — look for log messages indicating success)[notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. May 10 14:32:13.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

A questo punto soltanto, potrete essere certi che TOR stia usando un IP diverso da quello definito per la scheda primaria del sistema della vostra macchina, ed è quello che volevamo.

Buon divertimento. 

P.S: Direte voi: ma è pieno di documenti su come usare OutboundBindAddress: perché scriverci un post. Semplice: perché tanto è vero che è pieno di documenti in google che spiega come usare OutboundBindAddress quanto non se ne trova uno che spieghi che se oltre a OutboundBindAddress non configurate anche la variabile Address corca che funziona !! 🙂

JC

Licenza Creative Commons
Questo articolo è rilasciato sotto una licenza Creative Commons Attribuzione – Non commerciale – Non opere derivate 2.5 Italia License.

Connessione automatica di apparato bluetooth all’avvio di un Linux Debian/Ubuntu based

Non capiterà a molti, ma può succedere di avere un mouse o una tavoletta di puntamento collegati via bluetooth al vostro sistema Ubuntu, o Linux bastato su Debian/Ubuntu in generale.

Come avrete sperimentato, si deve: avviare il demone bluetooth a mano e fargli riconoscere e fare il paring la prima volta con l’apparecchio.
La cosa noiosa, è che ad ogni riavvio del sistema si deve
  1. partire con un mouse usb collegato
  2. attivare la connessione dell’apparecchio bluetooth a mano tramite l’icona in basso a destra
  3. scollegare il mouse usb.
 
Beh questo non è del tutto vero: esiste, come quasi sempre, una soluzione per automatizzare la connessione del vostro apparato bluetooth all’avvio del sistema, ed ora vediamo come.
Innanzi tutto ci serve che sia installato il pacchetto bluez-compat:possiamoinstallarlo sia dal gestore pacchetti o più velocemente, secondo me, dalla console lanciando il solito comando sudo apt-get install bluez-compat.
Fatto questo dobbiamo conoscere l’indirizzo MAC(1)dell’apparecchio che ci interessa. Se abbiamo già collegato una volta l’apparecchio in questione possiamo ricavarlo direttamente dal gestore bluetooth: aprendolo troviamo le informazioni riguardante l’apparecchio con incluso il suo indirizzo MAC(1)tipo 28:37:37:2B:0E:26. Attenzione: a volte l’indirizzo MAC(1)viene proposto come 28-37-37-2B-0E-26. Fosse anche sostituite, nel prossimo passaggio il carattere (meno) con il carattere (due punti)ed andrà benissimo.
Se non riusciamo a trovarloin questo modo possiamo farlo usando il comando hidddalla console, eseguite:
hidd –search
Che vi darà una lista degli apparati bluetooth collegati almeno una volta al sistema. Se non lo trovate nemmeno li cercatelo tramite il comando dmesgsempre da console.
A questo punto dobbiamo modificare il file /etc/rc.localperché questo file si occupa di caricare quello che indichiamo durante il boot del sistema.
 
Il file, se non lo avete mai modificato si presenterà così:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
 
Exit 0
 
Come dice la riga, nel file stesso questo scritp, così com’è non fa nulla, ma modificandolo aggiungendo la riga :
hidd –server –connect 28:37:37:2B:0E:26
PRIMAdella riga finale che riporta Exit 0farà esattamente quello che ci serve, ossia attiverà il nostro apparecchio bluetooth automaticamente: questo eviterà la noiosa procedura del dover avviare il nostro Linux con un mouse usb collegato, collegare a mano il nostro apparato bluetooth ed infine scollegare il mouse usb. Dopo la nostramodifica il file /etc/rc.local apparirà così:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will “exit 0” on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
 
hidd –server –connect 28:37:37:2B:0E:26
 
exit 0
 
Come vedete l’unica, ma sostanziale, differenza è la riga in cui viene chiamato il comando hidd –server –connect xx:xx:xx:xx:xx:xx.
NOTA: l’indirizzo MAC(1)che ho usato, 28:37:37:2B:0E:26, è chiaramente quello del mio apparato; voi dovrete usare quello che avete rilevato dal vostro sistema in quanto collegato al vostro apparato.
E questo è tutto: da questo momento al riavvio, se l’apparato bluetooth sarà acceso, il sistema lo riconoscerà e di conseguenza lo renderà attivo e disponibile. 
JC
 

Configurazione scheda di rete con IP STATICO su KDE

Il problema fondamentale della configurazione di un IP statico in KDE è dovuto fondamentalmente a quel maledetto gestore di rete integrato, che per non so quale motivo, ed ho perso anche troppo tempo ad indagare, non si riesce a configurare come uno vorrebbe.
 
Di pagine su internet su come configurare un IP statico sotto debian/ubuntu ce ne sono a bizzeffe, ma purtroppo a causa proprio di quel maledetto gestore di rete integrato, non funzionano. La mia soluzione è stata aggiungere una riga alle istruzioni solite di configurazioni di ip statico per debian/ubuntu.
 
Vediamo adesso tutti i passi:
 
  • Prima di tutto dobbiamo eseguire in un terminale il comando ifconfig questo ci servirà dopo durante la configurazione;
  • DISABILITARE il gestore di rete per la parte che ci riguarda: nel mio caso la rete via cavo; ossia clicchiamo sul pulsante ‘Disconnetti’ a fianco alla chiave inglese sulla riga della nostra connessione;
  • apriamo il nostro bel terminale;
  • andiamo in utente root per non dare sudo ad ogni comando: su – root (nel caso non abbiamo configurato una password per root allora TUTTI i comandi che leggerete dovranno essere anticipati dalla parola sudo. Quindi se vedete un vi /etc/resolv.conf e non potete farlo da root direttamente scriverete sudo vi /etc/resolv.conf; chiarito questo, andiamo avanti).
  • prima di tutto configuriamo in maniera permanente il nostro DNS Server. Se, come di solito consigliato, modificate il file /etc/resolv.conf non otterrete nulla perché questo file viene riscritto, ad ogni avvio, da una quaterna di file che sono presenti in /etc/resolvconf/resolv.conf.d/ essi sono:base, head, original e tail. Quello che interessa noi è Head. Lo modifichiamo con il nostro editor preferito, io uso vi, ma qualunque editor che gestisca testo puro va benissimo, e lo modifichiamo mi questo modo:
          /etc/resolvconf/resolv.conf.d/head
  • la voce search se sapete cosa sia, compilatela, altrimenti non mettetecela proprio. L’ordine d’uso dei server DNS elencati e dall’alto verso il basso: se il primo incontrato non risponde viene interpellato il secondo e così via. 
  • Sistemato questo passiamo alla definizione di rete, per farlo dobbiamo modificare il file /etc/networks/interfaces; ricordate il comando ifconfig che abbiamo eseguito all’inizio ? Bene da li prendiamo il nome della nostra scheda di rete, nel mio caso eth0, e configuriamo il file in questo modo:
        /etc/network/interfaces
  • La parte che ci interessa è quella dalla riga auto eth0 in giù compresa; chiaramente modificate l’ip, la netmask, il gateway, la network, il broadcast e dns-servers a seconda delle vostre necessità. Nota per la riga dns-nameserver: potete mettere più di un server in coda usando la virgola tra i vari ip, ma tenete a mente che se aggiungete più di un server DNS DOVETE aggiungere una lettera s al comando dns-namserver. Quindi se decidete di usare i due server di OpenDNS la riga sarà dns-namservers 208.67.200.200,208.67.222.222 Occhio: se non mettete la S in caso di più server o la mettete con un solo server durante l’inizializzazione della scheda di rete vi darà un errore.
  • A questo punto tutti i manuali dicono che la cosa è fatta!! Riavviate e … non funziona !!! Da questo punto ci ho messo delle ore a trovare una soluzione, e l’unica che ho trovato è la seguente: dovrete aggiungere al file /etc/hosts una riga in cui assegnate al vostro ip statico il vostro hostname. Non farlo, come facevo io seguendo le mille guide trovate in internet vi farà perdere solo tempo e pazienza: non so perché questa cosa risolve il problema però funziona!! Quindi se nel file /etc/networks/interfaces avete dichiarato address 192.168.1.130 dovete aggiungere nel file /etc/hosts una riga, consiglio appena sotto quella dichiarativa di 127.0.0.1 che è presente sempre, la riga 192.168.1.130 il_vostro_hostname. Voi mi chiederete « e dove diavolo lo trovo il mio hostname?». Semplicissimo: nel terminale digitate il comando hostname -a il risultato sarà il vostro hostname che userete nel file /etc/hosts.
  • A questo punto, e solo ora, potrete riavviare il vostro sistema ed avere configurato l’ip statico come volevate voi!!!! Ricordatevi che se in futuro cambierete il vostro hostname dovrete aggiornarlo di conseguenza nel file /etc/hosts altrimenti sarete di nuovo senza rete.
  • Per quanto riguarda il maledetto gestore di rete KDE non vi preoccupate se al riavvio avrà un punto di domanda in baso a destraKde-networkmanager: è perché lui non ha più il comando: fregatevene!!!!
 
Questo è quanto: è l’unico workaround che sono riuscito a metter in piedi per gestire un IP statico usando KDE. Esisterà magari una soluzione più elegante, ma io non l’ho trovata: ho tentato di configurare il gestore di rete di KDE in tutti i modi possibili, ma non son mai riuscito a fargli fare quello che volevo io. Per cui questa è la mia soluzione. Se ne trovate una più elegante: ben venga!!
 
JC

Osx script per la gestione DNS

Mi è capitato diverse volte di voler cambiare i DNS al volo per i più disparati motivi, e diciamocelo la procedura standard di chiamare Preferenze di Sistema —> Network e poi dover scegliere la scheda che ci interessa e poi cliccare su Avanzate e poi selezionare la scheda DNS e il doversi ricordare che sino alla pressione del pulsante Applica le modifiche non vengono attivate è un po macchinosa, per cui mi sono fatto questi diversi script per le varie situazioni. Chiaramente possono essere modificati senza problemi per configurare il DNS che più ci interessa, io ho impostato negli script il server DNS di google e di OpenDNS per stare sul generico, ma nessuno ci impedisce di configurarne altri.
 
Personalmente la necessità di manipolare i server DNS mi si è presentata usando DNSCrypt. Cosa è DNSCrypt? Un sistema per criptare tutte le richieste fatte ai server DNS. 
L’installazione di questo pacchetto, per quanto mi riguarda almeno, fa parte di una politica di resa difficoltosa da parte di terzi, che sia NSA o i nostri servizi o google o chiunque altro, di farsi gli affari miei quando interrogo un server. 

Chiaramente questa politica richiede altri accorgimenti come l’uso di reti anonimizzate come TOR, ma questo esula dallo scopo di questo post. Potete trovare info aggiuntive sull’uso di reti anonimizzate in questo post del mio blog: http://blog.joevr.org/2012/06/utilizzo-di-tor-favore-della-nosrtra.html

 
Le procedure di cambio parametri di sistema richiedono l’uso di sudo, visto che sono necessari i permessi di amministratore, ma non vi preoccupate se chiamate lo script senza, magari da Finder: al momento di applicare le modifiche, se non avete usato sudo, lo script invocherà, da solo la procedura di autenticazione necessaria.
 
Il file con gli script lo potete troavre qui, il file contiene i due script, uno per la scheda eternte ed uno per la scheda WiFi ed i corrispondenti file MD5
JC
Licenza Creative Commons 
Quest’opera è stata rilasciata con licenza Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 4.0 Internazionale. Per leggere una copia della licenza visita il sito web a questo URL.
 

Osx: vedere e non vedere in Finder file nascosti e cartella Libreria

Capita spesso, agli utenti Mac, di aver bisogno di vedere nel Finder, il file manager di Osx, i file nascosti, quelli prefissati da un punto come .bash-history, oppure la cartella Libreria nella propria home.
 
Google è piena di pagine che indicano la soluzione con l’uso di comandi da dare nel terminale, e dove possibile invece, le sequenze di comandi da dare attraverso la GUI.
Molti utenti del mondo Mac però non sono degli smanettoni per cui chiedere loro di “manovrare dal terminale” crea un certo disagio. Per altri che invece abbisognano spesso di modificare queste opzioni il dover accedere al terminale e dare e ridare il comando di continuo può essere noioso: almeno lo è diventato per me alla lunga.
Così mi son deciso di creare un paio di scritp che restando nel contesto della GUI di Mac aiuti a sveltire la cosa; i due scritp sono rispettivamente:
    1. VisualizzaFileNascosti
    2. VisualizzaLibreria
I nomi son auto esplicativi direi: il primo fa lo switch tra il vedere non vedere nelle finestre di Finder i file nascosti, il secondo invece fa lo switch tra il vedere o meno la cartella Libreria della propria home.
 
Ho creato il tutto via AppleScript, che tra le altre cose permette di creare, a lavoro finito, una applicazione a tutti gli effetti. Ho depositato queste due applicazioni nella cartella Applicazioni locale, quella nella mia cartella $HOME, ma nulla impedisce di installarli nella cartella Applications di sistema sotto la root.
I due script permettono di variare lo status attuale o di uscire senza modificare nulla, questi due snapshot:
 
 
 
 

Nella cartella, che ho condivisa, ci son sia il sorgente degli scritp che i dmg per l’installazione, creati dal comodo App2Dmg, che permette di creare il classico DMG di installazione da una cartella applicazione esistente.
La cartella da cui scaricare sia i sorgenti che i due dmg è la seguente:  http://joevr.mooo.com/owncloud/index.php/s/FEno18ViGjbUR0x 

Se a qualcuno può interessare scarichi pure: senno lasciate pure li 🙂

JC

Licenza Creative Commons 

 

Quest’opera è stata rilasciata con licenza Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 4.0 Internazionale. Per leggere una copia della licenza visita il sito web a questo URL.

WordPress con lettere accentate

Una delle più comuni problematiche quando si installa WordPress o si trasferisce un proprio blog wordpress da un server all’altro è quella delle lettere accentate che non vengono più visualizzate correttamente.

Di norma ci troviamo con dei punti interrogativi seguiti da simboli che nulla hanno a che fare con la nostra lettera accentata del momento.

Il problema è collegato alla definizione di una variabile di ambiente di php: per la precisione da DB_CHARSET che o non è configurata del tutto o non è configurata correttamente; come risolvere? Ecco qui i passi da seguire:

  1. Entriamo nel nostro server;
  2. Ci spostiamo nella cartella dove si trova il file di configurazione del nostro wordpress; di solito /etc/wordpress;
  3. apriamo con il nostro editor preferito con i permessi di amministrazione il file wp-config.php; nel mio caso usando l’editor si sistema il comando sarà: sudo vi wp-config.php
  4. a questo punto cerchiamo nel nostro file la riga define(‘DB_CHARSET’, ‘uft8’);

Adesso potremmo trovarci in due situazioni diverse: nel primo caso la riga proprio non esiste nel nostro file, nel secondo esiste ma è commentata, quindi inclusa in una  sequenza tipo questa:  /*  define(‘DB_CHARSET’, ‘uft8’); */

Nel primo caso basterà inserire la riga define(‘DB_CHARSET’, ‘uft8’);  sotto la riga che inizia con  define(‘DB_HOST’, ‘qualcosa’);

Nel secondo caso si dovranno cancellare i caratteri di commento ossia /*  ed  */

Per quanto riguarda il codice di codifica del charset si potrà usare quello più simile alla lingua necessaria, nel caso italiano ISO 8829-15; oppure quello più indicato per la lingua che si deve utilizzare. Potete trovare la lista completa dei codici utilizzabili a questo link.

In linea di massima però il codice più comodo, e che di solito comprende quasi tutti i caratteri più comuni, è per l’appunto l’utf8 di cui potete trovare le specifiche qui.

Una volta sistemato il vostro file di configurazione per wordpress, salvatelo, ed aggiornate la pagina del vostro blog: magicamente tute le lettere accentate saranno di nuovo al loro posto.

NOTE:

  1. Do per scontato che il database, su cui il vostro wordpress si appoggia, sia già configurato per gestire le lettere accentate. Eventualmente scriverò, più avanti, un post anche su come risolvere lo stesso problema usando MySql come motore database.
  2. Se avete accesso al vostro account solo via ftp, nessun probelma: scaricate il file, modificatelo e poi ricaricatelo.

 JC

Licenza Creative Commons 

 

Quest’opera è stata rilasciata con licenza Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 4.0 Internazionale. Per leggere una copia della licenza visita il sito web a questo URL.

ownCloud e nextCloud: Limite massimo dimensione file in upload

Dopo aver provato questo sistema di sharing su un mio server in internet, ho trovato un fastidioso problema: quando devo caricare file di dimensioni maggiori di 512Mb il sistema me lo impedisce.

Come prima cosa sono andato a verificare i limiti in /etc/phpX/apache2/php.ini (con X uguale a 5 o 7, dipende che versione usate di php) e per la precisione:

  1. che la variabile upload_max_filesize fosse maggiore di 512mb
  2. che la variabile post_max_size non fosse maggiore di 512mb, ed a dire il vero per un post direi che 128 sarebbero anche più che sufficienti
  3. che la variabile upload_tmp_dir fosse configurata a puntare una dir il cui file sytsem avesse spazio a sufficienza per caricare file delle dimensione massima nel caso in cui la /tmp di sistema non avesse spazio a sufficienza.

ATTENZIONE!!!

Nel configurare upload_max_filesize fate attenzione a NON superare il limite della ram a disposizione: in passato facendolo sono incappato in problemi di crash del sistema di cui non capivo il motivo, in quanto apparentemente non collegato a quel settaggio; ed in ogni caso il massimo consigliabile sarebbe la vostra ram installata diviso 2.

Ricaricato apache, con il classico service apache2 reload, il cambio del valore della variabile upload_max_filesize non sembrava aver risolto il problema:*Cloud continuava a darmi errore nella dimensione massima caricabile dal client: sia locale che da webclient. Dopo aver cercato a destra ed a manca, alla fine ho trovato l’impaccio: cercavo qualche configurazione specifica a 512Mb nella cartella di *Cloud ma non avevo verificato in .htaccess ed è proprio li che sta l’inghippo; apritelo e modificate il valore del settaggio di php_value upload_max_filesize 512M al valore che vi serve, nel mio caso php_value upload_max_filesize 1024M. 

Potete usare anche la notazione 1G come riportato qui: http://php.net/post-max-size.

 

Da questo momento in poi, ha accettato, senza problemi, file sino ad un gigabyte di dimensione direttamente dal client locale.

L’unico problema che non era ancora risolto, stava nel fatto che quando si passa il mouse sulla freccia di caricamento dal webclient continuava a segnalare che la dimensione massima caricabile era di 512MB; questo problema si risolve modificando, sempre in .htaccess, anche il valore di php_value post_max_sizea 1024M.

Non chiedetemi perché, visto che la variabile che determina la dimensione massima è upload_max_filesize: probabilmente un baco che proverò a segnalare a chi manutenziona il programma.

Do per scontato, che fosse chiaro che tutte le modifiche che ho segnalato vanno effettuate nel server dove il demone di onwCloud viene eseguito, e non sul sistema, Linux o Pc o Osx che sia su cui è installato il client 🙂

Sperando che possa essere di aiuto a qualcuno, vi auguro buona giornata.

JC

Licenza Creative Commons 
Quest’opera è stata rilasciata con licenza Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 4.0 Internazionale. Per leggere una copia della licenza visita il sito web a questo URL.

Creare regole personali per HTTPSEverywhere

Per creare delle regole personali da aggiungere ad HTTPSEvrywere, in questo specifico sotto TORBundle si procede così:

– Spostarsi sotto la cartella dedicata alla regole aggiuntive dle plugin HTTPSEvrywere ossia: /Applications/TorBrowser.app/Data/Browser/profile.default/HTTPSEverywhereUserRules  

– Creare un file con estensione .xml; il nome dovrebbe, ma non necessariamente, essere lo stesso che utilizzerete nel campo ruleset name= all’interno della regola stessa

– Creare la regola seguendo le istruzioni riportate qui: https://www.eff.org/https-everywhere/rulesets.

– Salvare il file e poi riavviare TorBrowser oppure Firefox o il browser per il quale state scrivendo la regola.

Considerate, in questo esempio, l’accesso al sito (www.)joe.vr.it che non supporta il protocollo https.

        target host=”joe.vr.it />
        target host=”*.joe.vr.it />

 

Praticamente diciamo ad HTTPSEverywhere che nel caso venga chiamato https://(www.)joe.vr.it la chiamata deve essere reindirizzata al protocollo http.

Questo può venir comodo, quando si incontrano siti che non supportano il protocollo https ed  HTTPSEverywhere non riesca a gestirlo da solo.

Le istruzioni qui riportate sono state scritte per TorBrowser su piattaforma Osx, ma possono essere usate tranquillamente sotto qualsiasi browser: il trucco sta sempre nel trovare la cartella HTTPSEverywhereUserRules riferita al browser che state usando, nella struttura del proprio sistema operativo.

A me ha fatto parecchio comodo per diversi siti, spero serva a qualcuno altro!!

JC

Licenza Creative Commons 
Quest’opera è stata rilasciata con licenza Creative Commons Attribuzione – Non commerciale – Condividi allo stesso modo 4.0 Internazionale. Per leggere una copia della licenza visita il sito web a questo URL.