Re: OT: Errore creazione wordpress site "Could not FTP to the domain"

2021-09-06 Thread Mauro



Il 05/09/21 12:55, Antonio ha scritto:
Ho anche inoltrato domanda di richiesta supporto Aruba (per la prima 
volta quindi vedremo ) ma ho la strana sensazione che o non viene 
risolto oppure ci vorrà molto per risolvere.


Sono ore che cerco di installare WordPress ed ottengo sempre lo stesso 
errore. L'errore l'ottengo con qualsiasi versione di Wordpress e anche 
se cerco di installare Drupal da Softacolous.




off topics x off topics. pare che lui non riesca ad aprire una sessione 
ftp forse verso wordpress o un suo repository.


non fai prima a tirare giu' una versione di wordpress direttamente dai 
siti istituzionali, scompattarlo nelle cartelle di aruba e partire da 
li? La butto giu' cosi', che e' una procedura velocissima e tagli la 
testa al toro.



M:




Re: lvm e mdadm

2021-09-06 Thread Piviul

Il 03/09/21 16:42, gerlos ha scritto:
Inoltre è buona pratica non usare immediatamente tutto lo storage 
disponibile sui PV, ma anzi far crescere le dimensioni di logical 
volume man mano che emerge la necessità - così hai spazio sia per 
eventuali snapshot, sia per eventuale over provisioning che preservi 
lo storage.


Grazie Gerlos, in che senso "over provisioning che preservi lo storage? 
Ma usi l'over provisioning? Quindi hai fatto un volume logico come pool 
e poi i vari LV sul pool? Certamente se devo gestire macchine virtuali 
l'over provisioning è fondamentale ma nel caso di un file system 
locale... non vedo un gran vantaggio se gestisci lo spazio come dicevi 
cioè non assegnandolo tutto e facendo il resize alla bisogna...


Ma forse mi sono perso qualcosa.

Grazie un monte!

Piviul




Re: lvm e mdadm

2021-09-06 Thread Marco Ciampa
On Mon, Sep 06, 2021 at 09:58:07AM +0200, Piviul wrote:
> Il 03/09/21 16:42, gerlos ha scritto:
> > Inoltre è buona pratica non usare immediatamente tutto lo storage
> > disponibile sui PV, ma anzi far crescere le dimensioni di logical volume
> > man mano che emerge la necessità - così hai spazio sia per eventuali
> > snapshot, sia per eventuale over provisioning che preservi lo storage.
> 
> Grazie Gerlos, in che senso "over provisioning che preservi lo storage? Ma
> usi l'over provisioning? Quindi hai fatto un volume logico come pool e poi i
> vari LV sul pool? Certamente se devo gestire macchine virtuali l'over
> provisioning è fondamentale ma nel caso di un file system locale... non vedo
> un gran vantaggio se gestisci lo spazio come dicevi cioè non assegnandolo
> tutto e facendo il resize alla bisogna...
> 
> Ma forse mi sono perso qualcosa.
> 
> Grazie un monte!
> 
> Piviul
> 

L'over provisioning allunga la vita ai dischi SSD...

-- 

Saluton,
Marco Ciampa



Re: lvm e mdadm

2021-09-06 Thread gerlos

Il 06/09/21 09:58, Piviul ha scritto:

Il 03/09/21 16:42, gerlos ha scritto:
Inoltre è buona pratica non usare immediatamente tutto lo storage 
disponibile sui PV, ma anzi far crescere le dimensioni di logical 
volume man mano che emerge la necessità - così hai spazio sia per 
eventuali snapshot, sia per eventuale over provisioning che preservi 
lo storage.


Grazie Gerlos, in che senso "over provisioning che preservi lo 
storage? Ma usi l'over provisioning? Quindi hai fatto un volume logico 
come pool e poi i vari LV sul pool? Certamente se devo gestire 
macchine virtuali l'over provisioning è fondamentale ma nel caso di un 
file system locale... non vedo un gran vantaggio se gestisci lo spazio 
come dicevi cioè non assegnandolo tutto e facendo il resize alla 
bisogna...


Ma forse mi sono perso qualcosa. 



No, sono io che ho messo troppa carne al fuoco, scusami 😅

Le motivazioni sono 3: preservare lo storage, allocarlo in modo indolore 
quando emerge la necessità, fare snapshot.


Partiamo dal "preservare lo storage": stavo pensando agli SSD, in 
particolare a quelli più vecchi, in cui era uso lasciare spazio 
inutilizzato per agevolare il wear-leveling. Con gli SSD più recenti 
questo non dovrebbe essere più un problema. Ad ogni modo lasciare 
blocchi liberi (a meno che non ti serva riempirli!) "aiuta" anche con 
gli HDD, visto che un eventuale bad block sul disco può essere 
riallocato dal firmware tra quelli lasciati liberi, senza conseguenze 
sui dati. Al giorno d'occhi penso che che sia più paranoia che prudenza 😉



Passiamo a cose più utili: l'uso dello spazio disponibile. Se partizioni 
direttamente il ferro, non è raro avere una partizione per /, una per 
/home e una per la swap.


Se dopo l'installazione ti accorgi che hai creato una partizione troppo 
grande per / a discapito di /home, ti tocca almeno spegnere tutto e 
avviare da un sistema live e ripartizionare tutto per rimediare. 
Similmente, quando hai fatto l'installazione potresti aver valutato male 
lo spazio necessario per /boot, per /var o per la swap, o le tue 
necessità potrebbero essere cambiate nel frattempo, e potresti dover 
ripartizionare.


Con LVM questo non è un problema. Basta creare dei volumi logici di 
dimensioni appena appena maggiori di quelle che ti servono sul momento, 
ed estenderli quando emerge la necessità, visto che puoi estendere i 
volumi con file system ext4 e xfs al volo, senza smontarli.


Esempio: disco da 1TB, al momento dell'installazione lo hai partizionato 
in modo tradizionale ed hai fatto una partizione da 64 GB per /, 16 GB 
per swap, 64 GB per /var e il resto per /home.


Dopo un po' vedi che 64 GB sono troppi per il file system root, perché 
usi meno di 12 GB, mentre i 64 GB di /var ti stanno stretti perché hai 
diverse macchine virtuali e magari ti serve più swap. Ti tocca spegnere 
tutto, interrompendo i servizi, *fare un backup*, ripartizionare, e 
sperare di averci preso questa volta.


Oppure mettiamo che aggiungi un secondo disco da 1TB perché vuoi mettere 
quel sistema su RAID 1: ti tocca spegnere e ricostruire tutto.


Mettiamo invece che usi LVM: il tuo primo disco da 1TB sarà un volume 
fisico (chiamiamolo PV1) di un gruppo di volumi chiamato VG1. In questo 
gruppo di volumi crei questi volumi logici:


- rootlv da 16 GB
- swaplv da 16 GB
- varlv da 32 GB
- homelv da 100 GB

Rispetto alla volta precedente stai effettivamente impegnando 
16+16+32+100 = 164 GB del tuo storage, ed hai oltre 800 GB che puoi 
assegnare di volta in volta quando ti serve, *senza spegnere nulla*.


Per esempio, per estendere /home, /var e swap per soddisfare le tue 
necessità puoi fare così:


$ sudo lvextend -L +100G --resizefs /dev/VG1/varlv
$ sudo lvextend -L +100G --resizefs /dev/VG1/homelv
$ sudo lvcreate -L 64G VG1 -n swaplv2
$ sudo mkswap /dev/VG1/swaplv2
$ sudo swapon /dev/VG1/swaplv2
$ sudo swapoff /dev/VG1/swaplv
$ sudo lvremove /dev/VG1/swaplv
$ sudo lvrename /dev/VG1/swaplv2 /dev/VG1/swaplv    # così non devo 
correggere /etc/fstab


Come hai visto estendere i file system è facile e gli utenti non si 
accorgono di nulla.


La swap non la possiamo ridimensionare al volo, ma possiamo crearne una 
nuova e successivamente eliminare quella vecchia. Ma anche in questo 
caso facciamo fatto tutto in modo pulito e ordinato, senza interrompere 
alcun servizio e magari senza dover modificare /etc/fstab.


Mettiamo infine che hai aggiunto il secondo disco da 1TB e vuoi mettere 
/home sotto RAID 1. Con LVM semplicemente crei un nuovo volume fisico 
(chiamiamolo PV2), lo aggiungi al gruppo VG1, e converti il volume 
homelv con `sudo lvconvert --type raid1 -m1 VG1/homelv` *senza dover 
spegnere nulla*. 😲



Passiamo agli snapshot: se hai spazio libero sul gruppo di volumi, puoi 
fare snapshot dei volumi logici. Uno snapshot è una "fotografia" di un 
volume logico in un certo istante. Mentre esiste lo snapshot, LVM usa lo 
spazio libero sul gruppo di volumi per registrare le modifiche al volume 
originale (per qu