Eseguire uno script al boot di Linux

Per fare lo start di uno script all'avvio di Linux aggiungere il proprio script nella directory:

/ect/init.d/myscript

e dargli i permessi di esecuzione

chmod +x myscript

Lo script dovrà rispettare il seguente tracciato:

#!/bin/bash 
#chkconfig: 2345 20 80 
#description: Description comes here.... 
#Source function library. 
. /etc/init.d/functions 

start() { 
   # code to start app comes here 
} 
stop() { 
   # code to stop app comes here 
} 

case "$1" in 

start) 
   start 
   ;; 
stop) 
   stop 
   ;; 
restart) 
   stop 
   start 
   ;; 
*) 
   echo "Usage: $0 {start|stop|restart}" 
esac 

exit 0

La riga #chkconfig: 2345 20 80 definisce il runlevel al quale lo script deve essere fatto partire (sul 2°, 3°, 4° e 5° livello) e le priorità di start (20) e di stop (80).
Per verificare il runlevel al quale sta girando la vostra macchina date il comando in un terminale:

runlevel

 I runlevel sono così definiti:

• 1 Single user (super user)
• 2 multi user
• 3 multi user + network
• 4 (non utilizzato)
• 5 multi user, network + X11

I runlevel 0 e 6 servono rispettivamente per il system halt e per il reboot.

Una volta copiato lo script nella directory di init.d dare i seguenti comandi per testare lo start dello script: /ect/init.d/myscript start oppure chkconfig myscript start.

Infine aggiungere lo script al chkconfig:

$ chkconfig --add myscript
$ chkconfig --level 2345 myscript on 

e verificarne l'abilitazione:

$ chkconfig --list | grep myscript

Il troppo spesso dimenticato nohup

Per lanciare un comando da shell e farlo girare in background anche se chiudiamo il terminale:

$ nohup ./fooName &

In questo modo è possibile seguire l'output del comando lanciato sul file nohup.out:

$ tail -f nohup.out

Il comando continuerà a girare fintanto che il processo non verrà "killato":

$ ps -ef | grep fooName $ kill -9

Swappiness!

Se si utilizza una o più macchine virtuali, risulta particolarmente utile che le immagini non finiscano sulla swap (in genere più lenta in lettura e scrittura - accesso in 1ms - rispetto alla RAM - accesso in 1ns). Per evitare ciò basta modificare il file /etc/sysctl.conf aggiungendo o modificando il valore assegnato alla variabile di kernel vm.swappiness. Questo valore può variare da 0 a 100 dove:

• swappiness = 0 consente di non accedere alla memoria fisica (swap) per il più lungo tempo possibile
• swappiness = 100 sposta tutti i processi sulla memoria fisica liberando la RAM il prima possibile

Per verificare il valore corrente: 

$ cat /proc/sys/vm/swappiness

Per cambiarlo temporaneamente:

$ sudo sysctl vm.swappiness=10

Per rendere la modifica definitiva modificare il file:

$ gksudo gedit /etc/sysctl.conf

e modificare la  linea contenente la stringa vm.swappiness con il valore desiderato:

vm.swappiness=10

dopo il reboot il valore diviene effettivo.


[fonte: http://bit.ly/vOMpzQ]

Svuotare la swap senza il riavvio!

Per svuotare facilmente la swap senza fare il reboot del pc basta utilizzare i comandi:

$ su
# swapoff -a
# swapon -a

oppure si può creare uno script e lanciarlo con privilegi di root. Ad esempio, nel file emptyswap.sh:

#!/bin/bash
echo -e "\nOutput of free before:"
free -m
swapoff -a ; swapon -a
echo -e "\nOutput of free after:"
free -m
echo ""

Per eseguire lo script basta renderlo eseguibile e lanciarlo:

$ chmod +x emptyswap.sh
# gksu sh emptyswap.sh

[Fonte: https://wiki.archlinux.org/index.php/Empty_Swap]

Fan control!

Come gestire e tenere sotto controllo la velocità della ventola di un portatile IBM/Lenovo Thinkpad in base alla temperatura del proprio pc? Utilizzando il gestore thinkfan!

1) Installare thinkfan:

$ su
# apt-get update && apt-get install thinkfan

2) Aggiungere il modulo coretemp al file /etc/modules:

# echo coretemp >> /etc/modules

3) Caricare il modulo coretemp:

# modprobe -v coretemp

oppure su Fedora 17

# echo modprobe foo >> /etc/rc.modules
# chmod +x /etc/rc.modules

4) Per gestire la ventola in funzione della temperatura bisogna modificare il file di configurazione /etc/modules aggiungendo i sensori dai quali leggere la temperatura:

# gedit /etc/thinkfan.conf

e aggiungere il risultato del comando prima delle definizioni della temperatura:

find /sys/devices -type f -name "temp*_input"

Bisogna aggiungere ad ogni risultato del find il comando sensor:

sensor /sys/devices/platform/coretemp.0/temp1_input 
sensor /sys/devices/platform/coretemp.0/temp2_input 
sensor /sys/devices/virtual/hwmon/hwmon0/temp1_input

Il file deve contenere subito dopo le righe dei sensor le seguenti righe:

(0,    0,    55)
(1,    48,    60)
(2,    50,    61)
(3,    52,    63)
(4,    56,    65)
(5,    59,    66)
(7,    63,    32767)

Dove fra le parentesi viene indicato (livello_RPM, temp_min, temp_max).

Per il mio Thinkpad ho utilizzato il sensore di default:

sensor /proc/acpi/ibm/thermal

5) Aggiungere questa riga al file /etc/modprobe.d/thinkfan.conf:

options thinkpad_acpi fan_control=1 experimental=1

6) Ricaricare il modulo thinkpad_acpi:

# modprobe -rv thinkpad_acpi

# modprobe -v thinkpad_acpi

7) Nel file /etc/default/thinkfan cambiare il l'opzione di avvio automatico:

set START=yes

8) Far partire thinkfan:

# /etc/init.d/thinkfan start

Per verificare che stia funzionando vedere l'output del comando

$ cat /proc/acpi/ibm/fan

se i valori del livello cambiano fra 0 e 7 il demone sta funzionando.


[Fonte: http://thinkpad-wiki.org/Thinkfan#Ke..._Kernel_2.6.38
http://forums.fedoraforum.org/showthread.php?t=269200]

Come gestire la carica della batteria sul notebook

Per evitare di far fare inutili cicli di carica-scarica alla batteria del notebook, deteriorando inutilmente le celle di carica, anche quando si ha la possibilità di una connessione alla rete elettrica, sarebbe auspicabile separare l'alimentazione della batteria da quella fornita dalla rete. Si hanno due possibilità:

1) staccare fisicamente la batteria dal laptop (pratica noiosa che comporta il problema di una eventuale caduta di tensione e conseguente spegnimento del pc);

2) separare a livello software la gestione di ricarica della batteria (in poche parole inibire la ricarica se non si supera una determinata soglia di scarica).

Delle due, la seconda!

L'idea è semplice: basta intervenire sulla configurazione del gestore carica/scarica fra il livello di interfaccia utente (il sistema operativo) e il BIOS attraverso il System Management BIOS e le API messe a disposizione dal sistema: SMAPI (System Management Application Program Interface).

Questo è, ovviamente gestito da un modulo del kernel ad-hoc differente per ogni laptop.

Questa breve guida è incentrata sul modulo tp_smapi per pc IBM/Lenovo Thinkpad. Ogni comando si riferisce alla configurazione su Ubuntu 11.04 "Natty Narwhal".

Cominciamo.

1) Installiamo i moduli (se non già presenti):

$ su
# apt-get update && apt-get install tp_smapi-source

2) Carichiamo il modulo nel kernel:

# modprobe tp_smapi

e verifichiamo il suo caricamento:

# lsmod | grep tp_smapi

3) Per vedere quali sono la soglia minima di carica (per la quale la batteria deve essere ricaricata) e quella massima (alla quale si smette di caricare la batteria):

# cat /sys/devices/platform/smapi/BAT0/*_charge_thresh

4) Ora, per modificare queste soglie:

# echo 50 > /sys/devices/platform/smapi/BAT0/start_charge_thresh
# echo 80 > /sys/devices/platform/smapi/BAT0/stop_charge_thresh

In questo caso si è scelto di caricare la batteria fino al 80% della carica totale se raggiunge un livello di scarica del 50%.



Ora facciamo in modo che il tutto sia configurato all'avvio del sistema. Cominciamo col rendere la configurazione permanente:

5) Installiamo:

# apt-get install sysfsutils

6) Aggiungiamo alla fine del file di configurazione le seguenti righe:

devices/platform/smapi/BAT0/start_charge_thresh = 10
devices/platform/smapi/BAT0/stop_charge_thresh = 40

oppure, in modo più veloce, da riga di comando:

# cat >> /etc/sysfs.conf << EOF
# For a LiIon battery in a Thinkpad
devices/platform/smapi/BAT0/start_charge_thresh = 10
devices/platform/smapi/BAT0/stop_charge_thresh = 40
EOF

7) Infine, carichiamo il modulo del kernel all'avvio:

# echo tp_smapi >> /etc/modules

In generale, le regole da seguire per aumentare le prestazioni della batteria sono poche:

• ridurre i cicli di carica/scarica;
• non utilizzare/ricaricare la batteria in condizioni di particolare riscaldamento (principalmente su piani inadatti, come le coperte);
• mantenere la carica della batteria al di sotto del 50% della carica totale (per stressare meno gli ioni di carica all'interno delle celle).

Per una configurazione ottimale e per saperne di più sul funzionamento delle batterie a litio: How to prolong lithium based batteries.

[Fonte: http://www.thinkwiki.org/wiki/Tp_smapi#Installation_on_Ubuntu]

Maledette librerie: 32 o 64 bit?

Per risolvere automaticamente le dipendenze dovute alla mancanza di librerie (32 o 64 bit), esiste uno strumento utilissimo: getlib. Provare per credere!

0x01) Scaricare getlib-all.deb da qui oppure:

$ wget http://frozenfox.freehostia.com/cappy/getlibs-all.deb

0x02) Installarlo:

$ sudo dpkg -i getlibs-all.deb

0x03) Usarlo:

- per scaricare e installare tutte le librerie mancanti di un programma (ex. Skype)

$ sudo getlibs /usr/bin/skype

- per scaricare e installare le librerie in una versione specifica (a 32-bit)

$ sudo getlibs -l libogg.so.0 libSDL-1.2.so.0

-per scaricare e installare librerie a 32-bit dal nome del pacchetto

$ sudo getlibs -p libgtkglext1


[Fonte: http://ubuntuforums.org/showthread.php?t=474790]

Cpufreqd: quando fidarsi è bene ma non fidarsi è meglio!

Nel caso in cui si voglia intervenire manualmente nella regolazione della frequenza della CPU:

installare cpufreqd (nel caso in cui non sia già presente sulla propria distro):

# equo install cpufreqd

(i comandi si riferiscono a Sabayon Linux)

e far partire il demone:

# /etc/init.d/cpufreqd start

Per gestire e configurare il comportamento del demone editare il file /etc/cpufreqd.conf. In questo file decomentare le righe:

enable_remote=1

remote_group=root

e poi specificare (o modificare) i profili

[Profile]
name=Performance Low
minfreq=40%
maxfreq=80%
policy=ondemand
[/Profile]

Qui ho riportato il profilo ondemand dove viene specificata la frequenza minima in percentuale e quella massima.

Il nome della policy è specificato nell'output del comando:

# cpufreq-info

alla riga gestori disponibili.

Le regole di gestione per l'applicazione dei profili sono definite nel seguente modo:

[Rule]
name=AC Off - Low Battery
ac=off # (on/off)
battery_interval=0-30
#exec_post=echo 5 > /proc/acpi/sony/brightness
profile=Powersave Low
[/Rule]

In questo esempio viene applicato il profilo Power Low nel caso in cui la batteria sia in un intervallo di carica 0-30!

[fonte:  http://sabayon-mania.com/wiki/index.php?title=Cpufreqd:_come_gestire_al_meglio_la_frequenza_della_cpu]

Repository: dove, quando e perchè

ATTENZIONE: Pur essendo valido per qualsiasi distribuzione, questo articolo è rivolto principalmente agli utilizzatori di Linux Mint, Ubuntu e tutte le distro Debian derivate.

Tutto il sistema di installazione e gestione dei pacchetti sulla maggior parte delle distribuzioni GNU/Linux si basa sui repository. Ovviamente questo concetto esiste da quando esiste Linux. Infatti, tutte le distribuzioni gestiscono ormai i propri pacchetti quasi esclusivamente attraverso l'uso di questi "magazzini virtuali".

Per chi non avesse mai sentito parlare di repository gli basti digitare da terminale

$ sudo apt-get update

per vedere come Aptitude (conosciuto come APT - Advanced Packaging Tool) aggiorna le proprie liste di indirizzi disponibili. Questi indirizzi, se non sono stati modificati dall'utente, sono gli indirizzi di default inseriti dagli sviluppatori di Mint.

Come si sa, Linux Mint si "appoggia" ai repository di Ubuntu: ciò significa che i pacchetti installati non sono altro che i pacchetti creati per Ubuntu. Inoltre, per completezza, le estensioni utilizzate dai sistemi Debian derivati (Ubuntu, Mint, ...) sono tutte uguali e chiamate .deb (l'altra grande fetta di pacchetti hanno estensione .rpm per tutti quei sistemi derivati Red Hat, tipo Fedora).

Qualora non si trovassero pacchetti con estensione .deb è sempre possibile crearne di compatibili a partire da un .rpm attraverso l'uso di alien:

$ sudo alien -c nome_pacchetto.rpm

Questo comando creerà un paccheto identico al precedente ma con estensione .deb.

Ma come si installano i programmi su una macchima Linux? Non di certo cercando i pacchetti uno per uno e risolvendo tutte le dipendenze a mano (come si faceva tanto tanto tempo fa!). Oggi ci viene in aiuto il programma di gestione pacchetti: Synaptic, per i sistemi Debian derivati. Questo programma fa il lavoro sporco: cerca i pacchetti, risolve le dipendenze e installa i pacchetti. Ovviamente si occupa anche degli aggiornamenti.

Ma come lavora Synaptic? Da dove prende le liste pacchetti? Come gestisce gli aggiornamenti?

Eccoci finalmente ai repository!

ATTENZIONE: Le procedure che seguono sono particolarmente pericolose per la stabilità del sistema operativo. Procedete con cautela!

Linux Mint memorizza i repository in due modi:

1) attraverso il file source.list che si trova in /etc/apt/

2) attraverso file di indirizzi PPA (Personal Package Archive)

Nel primo caso, una volta lanciato il comando

$ sudo apt-get update

Aptitude scorrerà la lista degli indirizzi memorizzati nel file sources.list per verificarne l'effettiva funzionalità.

Possiamo sempre modificare la lista aggiungendo righe di indirizzi o commentando con # all'inizio della riga di indirizzo.

Come si nota aprendo il file:

$ sudo gedit /etc/apt/sources.list

negli indirizzi è indicata la versione di Ubuntu alla quale si fa riferimento.

Per quel che riguarda PPA il discorso è diverso. Quando si importano repository attraverso

$ sudo add-apt-repository ppa:user/ppa-name

dove user/ppa-name ovviamente deve essere sostituito con il PPA che ci interessa.

Questo crea un file all'interno di /etc/apt/sources.list.d/ con estensione .list nel quale sono contenute tutte le informazioni riguardante quel determinato repository: indirizzo, versione della distribuzione e estensione dei pacchetti. Tutto in un unico file. L'indirizzo del repository e la chiave di autenticazione (segnatura gpg) sono importate automaticamente. Per quanto riguarda la versione questa viene aggiunta in base a quella del sistema in uso.

Ovviamente anche questo file è modificabile e basterà aprirlo con un qualsiasi editor di testo per apportare le nostre modifiche (questo risulta particolarmente utile quando il repository appartiene ad una versione Ubuntu precedente alla nostra e bisogna intervenire a mano per cambiarne il nome).

Infine, due parole sulla chiave di segnatura GPG (GNU Privacy Guard): questo programma permette di verificare e autenticare i pacchetti contenuti nel repository PPA attraverso il riconoscimento di una chiave unica criptata. In generale, la chiave si può aggiungere manualmente (si è obbligati nel caso di modifica del file sources.list) attraverso la riga di comando

$ sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys signing_key

dove signing_key viene sostituita dalla chiave del PPA che ci interessa.

Installare ebuilds di terze parti con emerge

ATTENZIONE: Prima di installare pacchetti con Portage procedere come qui.

Per installare .ebuild scaricati qua e là dalla rete bisogna anzitutto aggiungere la seguente riga alla fine del file /etc/make.conf

PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/"

Poi creare la directory nella quale il sistema portage andrà a cercare il pacchetto .ebuild

# mkdir -p /usr/local/portage/nome_categoria/nome_pacchetto

(per sapere il nome della categoria consultare http://gentoo-portage.com/Browse)

Dopo di che non rimane che scaricare il pacchetto .ebuild nella directory appena creata (attraverso wget) oppure copiando il pacchetto precedentemente scaricato.

Ultimi due passaggi:

# ebuild nome_pacchetto.ebuild manifest

e finalmente

# emerge nome_pacchetto


Il sistema risolve da solo le dipendenze. In caso di pacchetti non presenti in Portage (molto raro!) ripetere la procedura.


[fonte: http://wiki.sabayon.org/index.php?title=HOWTO:_Example_of_Installing_3rd_Party_Ebuilds]

Aggiornamento kernel Ubuntu e Debian-derivati

Per aggiornare il kernel su Ubuntu e derivati:

aggiungere il repository

$ sudo add-apt-repository ppa:kernel-ppa/ppa

$ sudo apt-get update

Poi installare il kernel che si vuole:

$ sudo apt-get install linux-headers-2.6.* linux-headers-2.6.*-generic linux-image-2.6.*-generic

Dove * verrà sostituito dal numero del kernel che vogliamo.

Equo vs. Portage

In Sabayon convivono due anime: Entropy (Sabayon) e Portage (Gentoo) con i rispettivi frontend grafici (Sulfur e Portato). Nulla di male, poste alcuni capisaldi:

0x01) aggiornare i pacchetti di sistema con Entropy

0x02) mixare i due sistemi con

# equo rescue spmsync

# vim /etc/entropy/client.conf

Cercare la linea ignore-spm-downgrades=disable e sostituirla con

# ignore-spm-downgrades=enable

0x03) se si installa una nuova versione di Entropy scartare sempre il file di configurazione con un -9 quando si esegue # equo conf update

[fonte: http://sabayon-mania.com/wiki/index.php?title=Mixare_pacchetti_presenti_in_Entropy_e_Portage&oldid=1477]

...e se non si spenge???

No problema:

# emerge -1 baselayout sysvinit

# dispatch-conf

...e passa la paura!

[fonte: http://forums.gentoo.org/viewtopic-t-643037-start-0.html]

Tempo di migrazione!

Alcuni file di configurazione con le nuove versioni GNU/Linux sono migrati. Esempio:

/etc/conf.d/rc ---> /etc/rc.conf


/boot/grub/menu.lst ---> /boot/grub/grub.cfg

[fonte: http://www.gentoo.org/doc/en/openrc-migration.xml]

Il fantastico mondo di /opt

Nella directory /opt ho scoperto un mondo: in questa cartella si posso mettere gli eseguibili che non necessitano di compilazione essendo già prevista una subdirectory /bin inserita nel $PATH di sistema (fantastico!). Non rimane che linkare tutti gli eseguibili: dalla directory /opt

ln -s /cartella_programma/nome_eseguibile /bin/nome_eseguibile