6 Gen 2013 |
Durante l’installazione di un tema di WordPress, mi veniva chiesto di effettuare l’upload dei file:
Provando sia in FTP che in FTPS, appariva l’errore:
Username/Password incorrect for [nome-utente]
Per risolvere il problema ho verificato di avere il programma vsftpd (se non c’era, bastava installarlo con “sudo apt-get install vsftpd”) e ho fatto una copia di backup del file di configurazione “/etc/vsftpd.conf”:
$ cd /etc/
$ sudo cp vsftpd.conf vsftpd.conf.bak
Poi ho editato il file:
$ sudo vim vsftpd.conf
Ho tolto i # (commenti) alle righe:
#local_enable=YES
#write_enable=YES
e ho riavviato il servizio:
$ sudo service vsftpd restart
Infine ho riprovato ad effettuare l’upload e non ha dato errori [1].
Una volta terminato l’upload ho preferito ripristinare il file vsftp.conf per evitare eventuali problemi di sicurezza.
Nota
[1] Questa soluzione ha funzionato perché l’utente usato per l’accesso FTP è uguale a quello nella cui home c’è l’installazione di wordpress. Con altre installazioni occorrerà scegliere l’utente corretto (che avrà i permessi di scrittura sulle directory di WordPress).
6 Gen 2013 |
Mentre stavo installando un tema di WordPress:
dopo aver premuto su “Install Now”, è apparso l’errore:
Unable to create directory wp-content/uploads/2013/01. Is its parent directory writable by the server?
Per risolvere il problema ho aperto una shell del server [1] su cui stavo facendo i test, mi sono posizionato nella directory di installazione di wordpress e ho dato i permessi corretti alla cartella wp-content:
$ cd /home/utente/public_html/wordpress-test/
$ sudo chown www-data:www-data wp-content
Poi ho rilanciato l’installazione del tema e non ha dato più errori [2].
Note
[1] Server usato: Ubuntu
[2] Attenzione: in altre distribuzioni di Linux (probabilmente quelle NON-Debian-like) può darsi che l’utente di Apache2 non sia “www-data”, ma un altro. Verificare qual è e rilanciare il relativo comando.
In rete ho visto altre soluzioni secondo me molto pericolose come dare alla cartella “wp-content” permessi rwx-rwx-rwx (chmod 777). Ovviamente lo sconsiglio.
20 Gen 2011 |
Mentre avviavo una Debian, ho visto dei messaggi che mi hanno insospettito:
SIOCSIFNETMASK: No such device
SIOCSGIFADDR: No such device
eth0: ERROR while getting interface flags: no such device
eth1: ERROR while getting interface flags: no such device
Facendo:
$ ifconfig
veniva visualizzata solo l’interfaccia loopback, mentre con:
$ ifconfig -a
non c’erano più la eth0 e la eth1, ma la eth2 e eth3 (Figura 1):
Andando a vedere il log: /var/log/messages ho notato:
kernel: [..] udev: renamed network interface eth0 to eth2
kernel: [..] udev: renamed network interface eth1 to eth3
Successivamente ho controllato il file:
/etc/udev/rules.d/70-persistent-net.rules
e ho visto le seguenti righe:
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*c",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*d",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*6",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*7",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
A questo punto sono andato a controllare (sempre da ifconfig -a, vedi Figura 1) i MAC delle schede, ho commentato le prime due righe (con MAC diverso) e ho modificato le ultime due mettendo “eth0” e “eth1” al posto di “eth2” e “eth3” (Figura 2):
# PCI device 0x8086:0x1076 (e1000)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*c",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x1076 (e1000)
#SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*d",
ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*6",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
# PCI device 0x8086:0x1076 (e1000)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="*:*:*:*:*:*7",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
Dopo aver fatto ciò, ho riavviato ed è tornato tutto come prima.
SIOCSIFNETMASK: No such device
SIOCSGIFADDR: No such device
12 Nov 2009 |
Se durante l’installazione/upgrade di PostfixAdmin (in questo momento sto passando alla versione 2.3), accedendo all’indirizzo http://mioServer/postfixadmin/setup.php, vi compare a fine pagina il messaggio:
DEBUG INFORMATION:
Invalid query:
CREATE command denied to user 'postfix_admin'@'localhost'
for table 'config'
può significare che l’utente postfix_admin non abbia i permessi di creazione e/o modifica sul DB. Quindi dovete darglieli.
Se usate phpMyAdmin, accedete alla sezione “privilegi”, selezionate l’utente “postfix_admin” e cliccate sul simbolo “modifica privilegi”. Poi mettete i segni di spunta su CREATE e ALTER e cliccate su “Esegui”.
Se non usate phpMyAdmin, accedete a MySQL e lanciate i comandi per assegnare i privilegi suddetti all’utente postfix_admin.
2 Nov 2009 |
Per avere un elenco del software installato su una Debian, si può lanciare il comando:
$ dpkg --get-selections > installed_software
Questo comando ridirige l’output nel file “installed_software” che potrà essere visionato ad esempio con:
$ less installed_software
In caso di reinstallazione del sistema, si potrà usare quel file per installare lo stesso set di software:
$ dpkg --set-selections < installed_software
$ dselect
Dopo aver lanciato dselect, selezionare “i” per richiedere l’installazione e quindi confermare.
2 Nov 2009 |
Se dopo avere lanciato:
# spamassassin --lint
per controllare che la configurazione di Spamassassin sia andata a buon fine, vi viene restituito l’errore:
[2716] warn: config: failed to parse line, skipping,
in "/etc/spamassassin/local.cf": use_dcc 0
Potete modificare il file di configurazione /etc/spamassassin/local.cf, aggiungendo prima di “use_dcc 0” la seguente riga:
loadplugin Mail::SpamAssassin::Plugin::DCC
Riavviate spamassassin con:
# /etc/init.d/spamassassin restart
Verificate che l’errore non compaia più rilanciando:
# spamassassin --lint
