A quanto pare non è molto difficile aggiornare minikube su Ubuntu Linux, basta dare semplicemente i seguenti comandi:
$ wget https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
$ chmod +x minikube-linux-amd64
$ sudo mv minikube-linux-amd64 /usr/local/bin/minikube
Per verificare la versione installata dare il comando:
$ minikube versionEd è tutto!
Uno dei vantaggi di utilizzare il NAT su una macchina virtuale è che permette a quest’ultima di “uscire” sulla rete privata e pubblica con lo stesso IP della macchina host.
Uno degli svantaggi di utilizzare il NAT invece è che non è possibile contattare direttamente la macchina virtuale dalla macchina host o da qualsiasi punto della rete locale.
Per poter utilizzare quest’ultima funzione, come ad esempio gestire una macchina tramite ssh, bisogna utilizzare in VMWare la modalità di rete chiamata “Host-Only” e quindi non utilizzare il NAT.
E’ possibile, tuttavia, permettere alla macchina virtuale di utilizzare connessioni verso internet, cosi come con il NAT, configurando un server proxy. Tale server proxy va installato direttamente sulla macchina host.
Vi riporto qui di seguito la procedura per poter procedere in tal senso, con la consapevolezza che non si tratta di una guida esaustiva ma della configurazione specifica per il mio ambiente: sistema host con Windows 10 Pro e sistema Guest Ubuntu 19.10 e scrivo anche come appunto me stesso.
Attualmente la guida è limitata alla configurazione di apt in quando è l’unico strumento che al momento ho la necessità di far accedere ad internet, integrerò successivamente se dovessero sorgere nuove esigenze.
Configurazione del proxy web sulla macchina host Windows
La mia scelta, dopo una veloce ricerca su internet è caduta su AnalogX Proxy.
L’installazione e la configurazione è molto semplice ed avviene esclusivamente tramite il seguente menu:
dove nel campo Proxy Binding andate ad inserire l’indirizzo IP su cui si desidera ricevere le connessioni proxy in arrivo, in questo caso l’indirizzo IP della scheda di rete virtuale sulla rete condivisa con la macchina virtuale. Questo per evitare di fare da “ponte” per connessioni provenienti da qualsiasi interfaccia e dirette verso il web (potenzialmente provenienti anche dal web stesso).
Configurazione di APT sulla macchina virtuale Ubuntu
apt, a differenza del resto delle applicazioni del sistema operativo, necessita di una propria configurazione per poter utilizzare un proxy.
Per prima cosa occorre creare il file:
/etc/apt/apt.conf.d/95proxies
ed inserire le voci:
Acquire::http::proxy "http://192.168.209.1:6588";
Acquire::ftp::proxy "ftp://192.168.209.1:6588/";
Acquire::https::proxy "https://192.168.209.2:6588/";
dove 192.168.209.1 è l’IP che si è configurato nel server proxy.
A questo punto il comando apt potrà contattare internet per la gestione dei pacchetti anche nella modalità “Host-only”.
Riferimenti:
https://superuser.com/questions/1111538/how-do-i-configure-proxy-and-proxy-authentication-in-linux
Stando al chengelog dell’ultima versione di NetworkManager, sembrerebbe che sia stato introdotto (finalmente) la possibilità di collegarsi utilizzando la tecnologia WPS.
Non è ancora chiaro se sarà supportato a livello hardware, ad esempio i pulsanti WPS delle varie dongle WiFi o come questo sarà integrato nell’interfaccia o sarà relegato alla riga di comando.
Questa è una di quelle funzionalità che personalmente definirei obbligatoria per un sistema operativo che si possa definire desktop oriented, considerando che era presente anche ai tempi di Windows XP.
Sono a conoscenza del fatto che ci siano dei workaround da terminale per avere tale funzionalità , ma mi chiedo come mai NetworkManager, che si prefissa il compito della gestione universale della rete, non abbia mai pensato di integrarla.
Aspettiamo fiduciosi!
Mi ci stò impazzendo da giorni ma l’ho appena scoperto come fare, in particolare volevo impostare la massima frequenza del monitor per evitare un fastidioso sfarfallio dei caratteri.
Stante il fatto che vorrei evitare come la morte la modifica del file /etc/X11/xorg.conf, che fa molto anni ’80 e un po’ spinto anche dalla comodità di altri sistemi operativi, mi sono buttato alla ricerca di qualche soluzione alternativa, la prima che ho trovato è stata quella di dare il comando
xrandr --rate valore
soddisfatto, ma fino ad un certo punto. (Non posso certo mettermi ad aprire un terminale e dare questo comando ogni volta che accendo o riavvio il computer, e non ho voglia neanche di capire come si faccia uno script che me lo esegua automaticamente ad ogni avvio di Gnome)
Cosi ho continuato la mia ricerca, venendo a conoscenza di un paio di tool grafici per randr (Resize and Rotate), venendo a conoscenza di progetti come urandr (del nostro Alberto Milone) e arandr.
taglio secco, il primo installato da A.U.R. non parte proprio (command not found) e neanche a farlo partire localmente con python.
Il secondo invece parte, permette di cambiare risoluzione, rotazione, ma non fa quello che voglio, ovvero cambiare frequenza!
Confesso che mi son anche messo anche a leggere un po’ i sorgenti, sempre in python per cercare di capire come funzionava e se era possibile aggiungere questa funzionalità ma ho presto lasciato perdere quando ho capito che il programma non utilizzava una libreria apposita ma si limitava a richiamare il comando xrandr, copiarne il contenuto e propolo all’utente, permettendo modifiche sempre richiamando il comando, insomma una sorta di wrapper al comando xrandr.
Insomma, alla fine la soluzione definitiva si nascondeva proprio li, nel file
~/.config/monitors.xml
nella sezione “rate”, e questo è tutto, per ora.
edit: sembra che neanche questo medoto sia funzionante, ho trovato per ora un’altra soluzione.
Provare a cercare “messenger chiude marzo” in rete e vedrete una serie di risultati facenti riferimento ad una chiusura in data 15 marzo, bene oggi 16/03/2013 il software si connette tranquillamente… che si siano dimenticati di spegnere i server o che abbiano tirato fuori una data tanto per?
Ho l’impressione che sul mio modello, e forse su tutti, lo schermo sia montato al contrario, vi spiego perché.
Dal primo giorno che ho cominciato ad usarlo (mi son sempre riproposto di recensirlo qui, ma senza successo) ho notato che ci sono alcune app che forzano l’utente a tenere lo schermo orientato in un certo modo, senza possibilità di ruotarlo, ovvero con la webcam verso il basso i connettori Alimentazione/HDMI/MiniUSB verso il basso e i tastini del volume al lato destro.
Vi elenco i miei personali motivi secondo i quali questa posizione è al contrario:
Con il rilascio della versione stabile di Steam per Linux, approda nei repository di Ubuntu anche il pacchetto, installabile dal software center, ma non solo! Esso è presente anche nel repository community di Archlinux, quindi installabile con pacman.
vorrei tanto saperlo, dato che c’è gente che ancora lo s[u,o]pporta!
Devo ammetterlo, han fatto davvero un bel salto di qualità, ad esempio con l’introduzione della modalità storia, con un video introduttivo dalla grafica non ai livelli di toystory3, ma molto simpatico, dove un fantomatico leader della comunità GNU viene rapito da un drago su un’astronave che lancerà un ricatto al nostro amico Tux, al quale spetta sfidarlo per liberare il guru.
Si procede in una mappa entrando in delle aree speciali per attivare la sfida e sbloccare nuovi livelli guadagnando punti e coppe.
Anche se è stata migliorata la fisica come impatti e slittamenti quello che davvero non trovo cambiato è il comportamento troppo lineare del veicolo, in particolare l’impossibilità di derapare, tipica dei kart.
qui trovate i sorgenti: http://supertuxkart.sourceforge.net/
“ovvero come cambiare l’username che esegue il demone”
Se avete un headless pc adibito a muletto e volete utilizzarlo come “scaricatore di torrent” il programma che fa per voi è transmission-daemon e la guida che fa per voi è questa:
https://trac.transmissionbt.com/wiki/HeadlessUsage
Solo alcune precisazioni, con il passaggio di ubuntu ad upstart, si è un po sminchiato lo script di avvio del demone, che in particolare si occupava anche di settare l’utente al quale associare il demone in esecuzione, come spiegato qui.
Raggiungendo gli sviluppatori su IRC (freenode), mi son fatto dare qualche dritta (ci ero quasi arrivato da solo alla cartella interessata ma non avevo trovato il file di transmission, guarda caso ora che ci rivado sotto loro guida c’è…).
Prima di fare ogni operazione STOPPATE ogni eventuale istanza di transmission-daemon attiva:
sudo service transmission-daemon stop
Innanzitutto l’utente non si cambia più impostando USERNAME in /etc/init.d/transmission-daemon ma modificando questa riga
setuid username
in /etc/init/transmission-daemon.conf
ora però dovrete impostare come proprietario (chown), e gruppo (chgrp) il vostro username nei file presenti nelle seguenti directory:
/etc/transmission-daemon
/var/lib/transmission-daemon
A questo punto fate ripartire il demone con:
sudo service transmission-daemon start
NOTA BENE: ho notato che anche se ci sono degli errori, il terminale segna che il demone si è avviato con un messaggio del tipo:
fabio@muletto:/etc/transmission-daemon$ sudo service transmission-daemon start
transmission-daemon start/running, process 1975
Per controllare avete 2 metodi:
1) ps aux | grep transmission-daemon
vi dovrà dare l’instanza in esecuzione con in PID e l’utente associato
oppure provate a stopparlo di nuovo con:
/etc/transmission-daemon$ sudo service transmission-daemon stop
se non è attivo vi dirà:
stop: Unknown instance:
mentre se attivo:
transmission-daemon stop/waiting
Fabiolinux 