Visualizzazione post con etichetta fedora19. Mostra tutti i post
Visualizzazione post con etichetta fedora19. Mostra tutti i post

lunedì 4 agosto 2014

Post Installation fedora 18 ,19 e 20

Aggiornamento con Post-installation fedora 20:
http://tweak2.com/20-essential-things-to-do-post-installation-of-fedora/

Piccoli inconvenienti durante l'installazione di fedora18 e 19:
il layout della tastiera alla schermata i iniziale è rimasta inglese, non so se per colpa mia o per qualche baco dell'installer. Quindi i caratteri speciali nella password non sono quelli che uno si aspetta.
risolvi con
system-config-keyboard e scegli il layout giusto
se il comando non c'è, installalo con yum

Link utile per questa guida:
http://www.zealfortechnology.com/2013/01/fedora-18-post-installation-software_16.html
http://www.lffl.org/2012/05/fedora-17-semplice-guida-post.html

se possibbile cercate di fare tutto manualmente senza utilizzare tools o script che potrebbero corrompervi definitivamente il vostro Fedora. Io, con Fedora 17 ho provato un paio di volte l'emozione del KERNEL PANIC dopo aver utilizzato il tool
qualche operazione necessaria dopo aver installato Fedora 18 KDE 64bit:

su
yum update -y

yum install libreoffice -y

#se non è già installato
yum install firefox

yum install wget

#installazione delle rpm fusion: permettono di installare software di terze parti
su -c 'yum localinstall --nogpgcheck http://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-18.noarch.rpm http://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-18.noarch.rpm

#Installazione dei plugin Flash
#Per 32 Bit
su
rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-i386-1.0-1.noarch.rpm
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
#Per 64 Bit
su
rpm -ivh http://linuxdownload.adobe.com/adobe-release/adobe-release-x86_64-1.0-1.noarch.rpm
rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-adobe-linux
#Ed installiamo Flash Player digitando:
su -c 'yum install flash-plugin'

# se vuoi installare dropbox usa QUESTA guida, i comandi seguenti li trovi nella pagina di download di dropbox ma i risultati non sono entusiasmanti. Capita ad esempio che il demone non si avvia automaticamente.
cd ~ && wget -O - "https://www.dropbox.com/download?plat=lnx.x86_64" | tar xzf -
#Next, run the Dropbox daemon from the newly created .dropbox-dist folder.
~/.dropbox-dist/dropboxd

#installazione di chrome: bisogna andare sul sito di google
https://www.google.com/intl/it/chrome/browser/
l'rpm installerà anche la repository

#installazione di teamviewer:
ci ho perso mezza giornata: in fedora 19 la versione 8 si installa, avvia il demone ma non mostra nessuna schermata. Nessuna info dai forum. Poi l'illuminazione: installi la versione 7 che per fortuna funziona e poi installi la versione 8, killi tutti i programmi teamviewer residenti in memoria, riavvii il demone e finalmente parte!! Sto casino è probabilmente dovuto a qualche configurazione di Wine.

#importazione del DB di Banshee:
capita di avere programmi basati su DB open-source come Banshee o shotwell,
quando cambi macchina può succedere che il path del db sia cambiato. Per mettere a posto tutto consiglio di seguire il seguente post
http://cybolic.wordpress.com/2010/04/08/fixing-a-banshee-music-database/
dove al posto di sqlitebrowser ho installato sqliteman perchè non presente nelle rep di fedora

giovedì 2 agosto 2012

virtualizzare... da remoto!

Aggiornamento4: da fedora18 in poi
http://niranjanmr.wordpress.com/2013/03/20/auth-libvirt-using-polkit-in-fedora-18/

Aggiornamento3: finalmente! Bisogna avviare il servizio ssh sul server fedora che ospita le macchine virtuali: leggendo il blog di darchino.ch bisogna fare tre semplici passi:
1. Installare il pacchetto openssh-server (da root digitare: "yum install openssh-server")
2. Attivare la porta ssh (usando il programma firewall, per farlo partire da terminale digitate "system-config-firewall") mettete quindi la spunta alla porta 22 protocollo tcp
3. Attivare il server ssh sul proprio computer (sempre da root digitare "/sbin/service sshd start")
a questo punto si avvia il demone libvirtd con
libvirtd -d e quindi finalmente parte la connessione sul client
Ora ci sono 2 piccole noie da superare: la connessione o la potenza di calcolo del client sembrano troppo lenti per rendere scorrevole l'utilizzo della macchina virtuale. Teamviewer regola la qualità ottimizzando l'usabilità. Con virtual manager non è possibile. Però rimane la comodità di accendere o spegnere una macchina virtuale da remoto

Aggiornamento2: non riuscivo ad avviare il demone di libvirtd, ecco cosa succede
"# libvirtd -d
libvirtd: errore: Unable to obtain pidfile. Controllare /var/log/messages o eseguire senza --daemon per maggiori dettagli."
Sembrerebbe che il file è occupato da qualche altro applicativo come virtual manager ma invece scopro che non devo usare i privilegi di root per avviarlo.

Aggiornamento1:  http://linux.die.net/man/8/libvirtd

l'idea è questa: hai una macchina potente (server) dove puoi far girare qualche SO virtualizzato senza che l'operatore soffra problemi di appesantimento. Poi hai uno scassone tipo pentium 3 che riesci a far girare con qualche distro light di linux. Il bello sarebbe che lo scassone possa accedere al server e accendersi la macchina virtuale e quindi poter usare Microsoft XP o 7 senza hardware dedicato.
Come si fà?
Incominciamo a dire che server e client devono stare in una LAN
Seconda cosa, devono usare Virtual Machine Manager (VMM): una applicazione sviluppata da redHat
"The application logic is written in Python, while the UI is constructed with Glade and GTK+."
che funziona abbastanza bene sotto fedora
L'applicazione si basa su libvirt e può creare e gestire macchine QEMU, KVM o XEN.
Io ho installato un windows XP su piattaforma QEMU e funziona molto bene, molto meglio di virtualbox (si blocca e fa crashare anche il DE) o vmware (non si installa in fedora).
Insomma installi VMM sul server, ti installi una o più macchine virtuali e hai una console che ti permette di gestirle (accendi, spegni, controlli le risorse in uso). La cosa simpatica è che se chiudi la finestra della macchina e anche la console di VMM la macchina continua ad essere residente in memoria e disponibile a future interrogazioni.
A questo punto installi la console di VMM sul client scassone e quello che ti rimane da fare è un collegamento tramite prot ssh al libvirt-deamon del server per poter gestire da remoto le macchine virtuali come se stessi sul server.
Qui però le cose si fanno difficili, bisogna passare alla riga di comando ed impostare alcuni file di configurazione...
Avendo Fedora17 ho seguito le seguenti istruzioni
http://wiki.libvirt.org/page/SSHSetup
che poi ti deviano sulla seguente pagina
http://wiki.libvirt.org/page/SSHPolicyKitSetup

praticamente bisogna scrivere un file con estensione .pkla
un esempio è quello che ho scritto io che permette all'utente ettore di accedere alla libvirt

[Remote libvirt SSH access]
Identity=unix-user:ettore
Action=org.libvirt.unix.manage
ResultAny=yes
ResultInactive=yes
ResultActive=yes

Leggi gli aggiornamenti ad inizio pagina...