Anomena i desa...

Després de solucionar el problema de l'apagada del meu ordinador, m'he trobat que el navegador Chromium no arrencava correctament. Hi havia processos corrent, però cap finestra :-(

He buscat per internet i els motius poden ser diversos, així que he optat per la solució clàssica de d'informàtica: suprimir i tornar a instal·lar. En l'Ubuntu 20.04 Chromium s'instal·la via paquets snap, així que les comandes per fer-ho son les següents :

$ sudo snap remove chromium
$ sudo snap install chromium

I, com sol passar, a partir d'aquí tot ha tornat a la normalitat !

 Fa un temps que arrossegava un problema amb el meu Ubuntu 20.04: es quedava penjat a l'apagar-lo amb un error similar a (perdoneu si no és exacte, l'escric de memòria):

shutdown: waiting for process contained-shim to terminate

El problema és que es quedava "penjat" durant uns minuts, així que normalment l'acabava apagant forçant-lo (mantenint el botó d'apagat durant uns segons). A part que és emprenyador, sempre hi ha el risc de perdre dades...

Total, que avui he tingut un moment per mirar de corregir-ho. En principi, ho he relacionat amb els meus experiments amb Docker, així que l'he desinstal·lat. Malauradament, això no ha corregit el problema.

Llavors he recordat que també havia fet petites coses amb Kubernetes i, efectivament, aquest era el culpable. Com que ara mateix no el necessito, la solució ha estat eliminar-lo:

snap remove microk8s

I problema resolt: el PC s'apaga ens uns segons un altre cop !

Docker és possiblement el gestor de contenidors de programari més utilitzat actualment. Un contenidor ens permet obtenir els mateixos avantatges que una màquina virtual, però funcionant directament sobre el sistema operatiu hoste. Això permet que siguin més lleugers i eficients en general.

Per instal.lar Docker a Ubuntu, seguim el procediment descrit en la seva pàgina. De les possibles opcions, la més senzilla, sobretot de cara a possibles actualitzacions, és utilitzar un repositori. Per tant, primer instal·lem el repositori de Docker:

sudo apt-get update
sudo apt-get install apt-transport-https ca-certificates curl \
     gnupg-agent software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | \
     sudo apt-key add -
sudo add-apt-repository "deb [arch=amd64] \
     https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

I tot seguit ja podem instal·lar el Docker Engine:

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io

Si tot és correcte, ja estem en condicions de provar el nostre primer contenidor:

sudo docker run hello-world

El resultat ha de ser similar al de l'imatge:
Amb això, ja tenim l'entorn preparat per fer les primeres passes amb contenidors Docker. Tot a punt per divertir-se !!

Si desenvolupeu en Ubuntu i treballeu amb git és possible que ja utilitzeu el GitKraken. I si encara no ho feu, proveu-lo ! Segur que us agradarà: us deixo una imatge a sota per fer dentetes...


En tot cas, si treballeu en Angular o en projectes amb molts fitxers, us pot sortir el següent error en obrir el projecte:


Per evitar-lo només cal augmentar el nombre màxim de fitxers a supervisar (per exemple, seguint les indicacions de: https://github.com/guard/listen/wiki/Increasing-the-amount-of-inotify-watchers).

$ cat /proc/sys/fs/inotify/max_user_watches
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p

I problema resolt !

Fa temps que m'he acostumat a treballar amb múltiples espais de treball (escriptoris). En concret, jo utilitzo una configuració de 2x4.

Normalment, ho configuro amb alguna aplicació, però sempre em costa trobar el lloc concret on es defineix. Així que he buscat com fer-ho usant la línia de comanda i aquí teniu la solució:

 $ gsettings set \
   org.compiz.core:/org/compiz/profiles/unity/plugins/core/ vsize 2
 $ gsettings set \
   org.compiz.core:/org/compiz/profiles/unity/plugins/core/ hsize 4

I el resultat:

Observeu al centre l'intercanviador d'escriptoris de 2x4 !!

Fàcil i ràpid, eh?

Si treballeu amb Altera des de Linux, i Ubuntu en particular, segur que ja us haureu trobat amb més d'un problema, especialment a l'hora de simular amb Modelsim.

La darrera versió del Quartus Prime (16.0) no és una excepció. En anar a simular, he comprovat que no engega el Modelsim. L'error que dona no és gaire explicatiu i sembla indicar que falta la llicència.

Però estic utilitzant la versió gratuïta, pel no pot ser un problema de llicències.

Així que anem a comprovar què passa provant d'engegar el Modelsim des de la línia de comandes:

$ cd ~/altera/16.0/modelsim_ase/linuxaloem
$ ./vsim
./vish: error while loading shared libraries: libXft.so.2:
        cannot open shared object file: No such file or directory

Comprovo els paquets instal·lats i veig que la llibreria en qüestió està disponible. Potser no la troba i cal indicar-li explícitament. No seria el primer cop:

$ env LD_PRELOAD="/usr/lib/x86_64-linux-gnu/libXft.so.2" ./vsim
ERROR: ld.so: object '/usr/lib/x86_64-linux-gnu/libXft.so.2' 
       from LD_PRELOAD cannot be preloaded 
       (wrong ELF class: ELFCLASS64): ignored.
./vish: error while loading shared libraries: libXft.so.2: 
        cannot open shared object file: No such file or directory

Ara l'error ja està clar: ELFCLASS64 ho delata. El Modelsim necessita llibreries de 32 bits !

Som-hi:

sudo apt-get install libxft2:i386

Amb això ja puc executar el Modelsim des del Quartus Prime (o des de línia de comandes, si vull):


 Si a algú li serveix, pot deixar un comentari, que sempre fa gràcia de veure.

Si feu com jo i treballeu amb la darrera versió LTS (de llarg suport) d'Ubuntu, segurament no tindreu accés oficial a la nova i flamant versió 5.x del Libreoffice fins a actualitzar-vos a Ubuntu 16.04 Xenial. I encara ens queda pràcticament mig any d'espera !

Però podem gaudir-ne ja, fàcilment, simplement instal·lant-lo des d'un repositori alternatiu. No patiu, només hi versions estables, no betes !

Per fer-ho, anem al terminal i fem:

$ sudo add-apt-repository -y ppa:libreoffice/ppa

Ens preguntarà la clau i ens afegirà el repositori, tal com es pot veure en la imatge següent:


Tot seguit, actualitzem i instal·lem la nova versió amb:

$ sudo apt-get update
$ sudo apt-get install libreoffice

I ja ho tenim !!


A gaudir-ne !!!

Si busqueu un ordinador petit, bonic i a bon preu, l'Asus VivoPC VM42 pot ser una bona opció. El teniu a Amazon per poc més de 215€ (octubre de 2015). Per aquest preu, tampoc no n'espereu unes prestacions fora de sèrie. Però pot ser una bona opció per un petit servidor web o NAS, o per a navegar per internet sense gaires requeriments.


Per desgràcia, al posar-hi Ubuntu em vaig trobar que no podia arrencar des de l'USB. Es quedava penjat en la pantalla d'arrencada, amb diverses versions de Linux i diferents  memòries USB.

Per tant, es tractava d'un problema del PC, possiblement de les opcions d'arrencada en la BIOS.

Un cop identificat el problema, la solució és senzilla:

•  Entrar a la BIOS prement F2 en arrencar.
• Anar al menú de Boot -> Secure Boot Menu.
• Seleccionar Other OS en el tipus de sistema operatiu.

Finalment, cal sortir de la BIOS acceptant els canvis fets, i ja ho tenim.

A partir d'aquí, vaig poder instal·lar Ubuntu sense cap problema.

Fa uns mesos em vaig trobar amb un problema en un servidor, que es quedava en el GRUB esperant una tecla per arrencar. Això ja va quedar resolt, però aquesta setmana m'ha passat una cosa molt similar: un servidor s'ha quedat aturat esperant una tecla abans de provar de reparar el sistema de fitxers en arrencar, després d'apagar-se per una fallada elèctrica.

Sembla que Ubuntu fa que s'aturi la comprovació i es demani la intervenció de l'usuari (que normalment consisteix en prémer la tecla per provar de fer la reparació automàtica).

En fi, per evitar que això torni a passar, cal editar un fitxer de configuració i posar l'opció FSCKFIX=yes:

$ sudo nano /etc/default/rcS

Amb això ja arrencarà sense problemes la propera vegada que passi. A menys que hi hagi un problema gros de veritat, es clar !

Tot  sovint convé saber la versió d'Ubuntu en la que ens trobem, sobretot si treballem amb múltiples servidors al llarg del temps. Pot ser necessari per temes de compatibilitats, etc...

Si disposem d'entorn gràfic, n'hi ha prou d'anar a l'opció de "Quant aquest ordinador" dins del menú de sessions (la rodeta de dreta del tot de la barra d'eines):


Però en un servidor no disposem d'aquesta possibilitat. Per sort, tenim la comanda que en dirà la versió:

$ lsb_release -a

I també la que ens pot dir si estem treballant amb 32 o 64 bits:

$ getconf LONG_BIT

Senzill i molt útil !

Ubuntu, o Linux en general, disposa de petites joies en forma de comandes del terminal que ens poden fer la vida molt fàcil. O no us heu trobat mai amb la necessitat de saber quins fitxers heu modificat fa un parell d'hores? O fa un parell de dies?
La comanda següent:

$ find . -mtime -1 -ls

ens permet localitzar tots els fitxers modificats durant l'últim dia. Canvieu el 1 pel número de dies que vulgueu...

I si voleu menys d'un dia? No patiu, també hi ha la possibilitat de buscar per minuts. Així:

$ find . -mmin -60 -ls

ens permet trobar els fitxers modificats en la darrera hora.

Fàcil i útil, veritat?

Als que ja tenim una edat, de tant en tant ens agafa un rampell de nostàlgia. Deu ser per això que avui m'ha donat per instal·lar un emulador del que va ser el meu primer ordinador, el Commodoe 64.

Hi ha diverses opcions, però m'he decidit pel VICE, que ja el tenim present en la distribució:

$ sudo apt-get install vice

L'executem des del terminal per veure si genera algun error:


I efectivament, tenim un error. Si ens fixem en el que ens diu, podem veure que no ha trobat les ROMs per poder emular el C-64. Un tema de llicències.

Ho podem solucionar baixant el paquet amb el codi font, que sí que les inclou. Desempaquetem i copiem els fitxers necessaris:

$ sudo cp -vR vice-2.4/data/* /usr/lib/vice

I a recordar els bons vells temps:

Aquesta setmana he tingut un problema amb un servidor que no va arrencar. Vaig haver d'accedir-hi físicament, armat amb teclat i pantalla, per comprovar que simplement estava en el menú del GRUB, esperant una tecla per continuar!!!

Però si hi tinc posat un timeout! Havia d'arrencar sol al cap de tres segons. Cercant sobre el tema, de seguida vaig trobar un bug relacionat que em va portar a un altre bug on es descriu la font del problema: bàsicament, que s'ha afegit l'espera (infinita per defecte) d'una tecla quan el sistema no es va tancar correctament.

En resum, em va recordar allò de "no és una errada, és una prestació".

Per sort, conegut el problema, la solució és ben fàcil, ja que també es va introduir un opció per canviar el temps d'espera, o eliminar-lo completament. Vaja, una altra opció del GRUB que per desgràcia no ve en les configuracions per defecte.

Per solucionar-ho, editem el fitxer de configuració del GRUB a /etc/default/grub i afegim la línia (posant el timeout que vulgueu):

GRUB_RECORDFAIL_TIMEOUT=10

Tot seguit actualitzem amb les noves opcions:

$ sudo update-grub

I ja ho tenim solucionat!

El VirtualBox és un sistema de virtualització que ens permet mantenir servidors amb versions antigues de certes aplicacions, o bé provar diferents configuracions o sistemes operatius. Molt útil en desenvolupament multi-plataforma, també.

Sovint és convenient crear una màquina virtual "base" en el VirtualBox, ja preparada amb la versió correcta de les nostres aplicacions preferides. Desprès només cal clonar-la i canviar allò que sigui específic de cada servidor particular.

Aquesta estratègia requereix:

• Clonar la màquina virtual amb l'adreça MAC canvida.
• Canviar el hostname allà on toqui: /etc/hostname i /etc/hosts.

Però això pot no ser suficient, i en podem trobar en que la màquina arrenca perfectament, però no té accés a la xarxa. Ens apareix un error tipus "connect: Network is unreachable".

El problema sol ser degut a que el canvi de MAC ha estat considerat com si s'hagués afegit una nova targeta de xarxa (és a dir, ja no tenim eth0). Per solucionar-lo, el més senzill és obligar a recrear la configuració de xarxa amb:

$ sudo rm /etc/udev/rules.d/70-persistent-net.rules
$ sudo reboot

Amb això es recrea eth0 i la màquina virtual ja té accés a la xarxa !!!

En actualitzar la versió del PHP en un dels servidors Apache, em vaig trobar amb l'error: "Warning: date(): It is not safe to rely on the system's timezone settings.".

Sortosament, el problema és fàcil de solucionar. Només cal definir la zona horària en el fitxer php.ini:

$ gksudo gedit /etc/php5/apache2/php.ini

Tot seguit, reiniciem el servidor Apache:

$ sudo service apache2 restart

I problema solucionat !

En Ubuntu, o en Linux en general, de vegades trobem petites utilitats que ens fan la vida més fàcil. És el cas de zgrep, que ens permet buscar cadenes de text a l'estil de la comanda grep, però directament en fitxers comprimits amb gzip, però sense haver-los de descomprimir prèviament.

Per exemple, amb la comanda:

$ zgrep "BOOT_IMAGE" /var/log/dmesg*

Podem veure la línia de comanda amb la qual ha arrencat el nostre sistema Ubuntu les darreres vegades, tal com es mostra en la imatge.



Fixeu-vos com obtenim els resultats tant dels fitxers comprimits (*.gz) com dels que no ho estan.

Això resulta especialment útil per buscar informació en fitxers de registre del sistema. No trobeu?

Fa un temps vaig comentar com afegir una llançadora d'aplicacions per a Unity. En l'article es comentava com posar-lo al directori del sistema, per tal que estigui disponible per tots els usuaris.

Però de vegades pot convenir que només el vegi el nostre usuari (per exemple, jo ho he necessitat per a un script de compilació). El procés seria el mateix, però canviant el darrer pas per:

$ mkdir -p ~/.local/share/applications/
$ cp Web_Build.desktop ~/.local/share/applications/

I ja ho tenim:


D'acord. Admeto que podria haver escollit una icona millor. Però la idea ja la veieu, no?

Si tot sovint us heu de connectar a servidors per SSH, segur que agraireu poder-ho fer sense haver d'entrar la clau de pas (password) cada vegada.

El procés és senzill. En la màquina des d'on us voleu connectar i amb el vostre compte d'usuari, obriu un terminal i feu:

$ ssh-keygen -t dsa
$ ssh-copy-id -i ~/.ssh/id_dsa nom_usuari@IP_Servidor

La primera comanda genera una clau que us identifica (només cal fer-ho si no la teniu generada d'abans). El millor és deixar la frase de pas buida, per poder connectar directament. El resultat és una clau que s'ens mostra en hexadecimal i també amb una curiosa imatge ASCII.

Tot seguit, amb la segona comanda copieu aquesta clau al servidor. Heu d'indicar la IP (o nom) i també el compte amb el qual voldreu accedir.

El procés el podeu veure en la imatge de sota. I si el que voleu és accedir a un ordinador, amb això ja en tindreu ben bé prou.


Ara bé, per poder accedir a un encaminador (router) amb Gargoyle o Openwrt, el procés encara no ha acabat. Si hi accediu per SSH podreu comprovar que us segueix demanant el password. Això és degut a que utilitza el dropbear, i li hem d'indicar on pot localitzar les claus.

Per això, en l'encaminador, feu:

# mv /root/.ssh/authorized_keys /etc/dropbear/
# ls -l /etc/dropbear/

La primera comanda copia la clau al lloc adequat pel dropbear, mentre que la segona permet verificar que els permisos del fitxer són els correctes, per un tema de seguretat.

Ara sí, si sortiu de l'encaminador i proveu de tornar a connectar-hi amb SSH, comprovareu que ja no us demana la clau de pas, tal com es pot comprovar en la imatge de sota.


Còmode, veritat?

Fa poc em vaig trobar que un dels meus servidors no estava en hora. Com que està corrent en una màquina virtual, no hi tinc cap escriptori instal·lat, i, per tant, vaig haver d'actualitzar l'hora des de la línia de comandes.

Crec que val la pena anotar-ho per una altra vegada. La comanda és:

$ sudo ntpdate time.nist.gov 

I el resultat:
Amb això actualitzem l'hora des d'internet, amb un rellotge de precisió.

Després d'una actualització rutinària de l'Ubuntu Saucy (13.10), m'he trobat que el navegador de fitxers, Nautilus, peta només d'engegar-lo. Per tant, impossible treballar.

Si us trobeu en un cas similar, el primer que cal fer és engegar-lo des del terminal, per veure quin error ens pot estar donat:

Violació de segment. Tal com em pensava.

A més, veig que algunes de les extensions s'han carregat correctament. Però segur que alguna altra no. El primer que cal fer és treure les extensions sospitoses:

$ cd /usr/share/nautilus-python
$ sudo mv extensions/ extensions_old 

Fet això, tornem a provar d'engegar el nautilus. Sense problemes aquest cop. Perfecte.

Ja només queda anar provant les extensions una a una, fins a detectar la que fa petar el navegador. I a treballar de nou com si res !