rc.local ed Ubuntu 17.04

Quanto serve un qualcosa che parta alla fine dello startup del sistema operativo!!

Ma con Ubuntu 16.10 (e forse anche prima) con il passaggio a Sytemd è stato tolto l’utile rc.local; per riabilitarlo bisogna eseguire i seguenti passi:

Dopo aver verificato che il servizio non è effettivamente attivo

sudo systemctl status rc-local
● rc-local.service - /etc/rc.local Compatibility
 Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled)
 Active: failed (Result: exit-code) since Thu 2015-11-26 23:54:58 CST; 59s ago
 Process: 1001 ExecStart=/etc/rc.local start (code=exited, status=1/FAILURE)
Nov 26 23:54:57 vivid rc.local[1001]: File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 920, in require
Nov 26 23:54:57 vivid rc.local[1001]: needed = self.resolve(parse_requirements(requirements))
Nov 26 23:54:57 vivid rc.local[1001]: File "/usr/lib/python2.7/dist-packages/pkg_resources/__init__.py", line 807, in resolve
Nov 26 23:54:57 vivid rc.local[1001]: raise DistributionNotFound(req)
Nov 26 23:54:57 vivid rc.local[1001]: pkg_resources.DistributionNotFound: shadowsocks==2.8.2
Nov 26 23:54:58 vivid sudo[1008]: pam_unix(sudo:session): session closed for user root
Nov 26 23:54:58 vivid systemd[1]: rc-local.service: control process exited, code=exited status=1
Nov 26 23:54:58 vivid systemd[1]: Failed to start /etc/rc.local Compatibility.
Nov 26 23:54:58 vivid systemd[1]: Unit rc-local.service entered failed state.
Nov 26 23:54:58 vivid systemd[1]: rc-local.service failed.
sudo systemctl enable rc-local
The unit files have no [Install] section. They are not meant to be enabled
 using systemctl.
 Possible reasons for having this kind of units are:
 1) A unit may be statically enabled by being symlinked from another unit's
 .wants/ or .requires/ directory.
 2) A unit's purpose may be to act as a helper for some other unit which has
 a requirement dependency on it.
 3) A unit may be started when needed via activation (socket, path, timer,
 D-Bus, udev, scripted systemctl call, ...).

bisogna abilitarlo editando il file

sudo vi /etc/systemd/system/rc-local.service

e modificarlo affinchè sia uguale a quello qui sotto:

[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

A questo punto abilitiamo l’esecuzione del file rc.local

sudo chmod +x /etc/rc.local

ed abilitiamo il servizio

sudo systemctl enable rc-local
Created symlink from /etc/systemd/system/multi-user.target.wants/rc-local.service to /etc/systemd/system/rc-local.service.

Controlliamo che tutto sia a posto

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service
● rc-local.service - /etc/rc.local Compatibility
 Loaded: loaded (/etc/systemd/system/rc-local.service; enabled; vendor preset: enabled)
 Active: active (running) since Fri 2015-11-27 00:32:56 CST; 14min ago
 Process: 879 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)
 Main PID: 880 (watch)
 CGroup: /system.slice/rc-local.service

Fatto !

(è possibile usare anche il crontab con la keyword @reboot … )

Errori di PAC durante lo startup

Da molto uso PAC per la gestione dei diversi ststemi sui quali lavoro, ma questo fine settimana dopo l’aggiornamento alla versione 17.04 di Ubuntu, è apparso un bel errore:

Use of uninitialized value in subroutine entry at /opt/pac/lib/PACKeePass.pm line 273.

dopo aver girovagato ho trovato la soluzione

apt install libglib2.0-dev libpango1.0-dev libvte-dev libvte-2.91-dev dh-make-perl
dh-make-perl --cpan Gnome2::Vte --build
sudo dpkg -i libgnome2-vte*.deb
sudo find /opt/pac/ -name "Vte.so*" -exec rm {} +

ma verso la fine della compilazione avevo questo errore

MakeMaker FATAL: prerequisites not found.
ExtUtils::Depends not installed
ExtUtils::PkgConfig not installed

ho installato allora i pachetti necessari con

apt install libextutils-pkgconfig-perl libextutils-depends-perl

e tutto è andato perfettamente.

Verifica di un host “up and running” ma senza ping

Avevo la necessità di verificare che un server fosse up and running, ma senza poter usare il ping in quanto disabilitato.
Girovagando mi sono imbattuto in un pezzo di codice perl che ho provveduto ad inserire all’interno di uno script bash:


[...]
FOO=`/usr/bin/perl -x $0`
echo <<'__END__' > /dev/null
#!/usr/bin/perl -wl
use IO::Socket::INET;
$| = 1;
my $socket = new IO::Socket::INET(
PeerHost => 'aaa.bbb.ccc.ddd',
PeerPort => '22',
Proto => 'tcp',
Timeout => 2,
);
die "cannot connect to the server $!\n" unless $socket;
print "connected to the server\n";
__END__

#/usr/sbin/ping $HOST
if [ "${FOO}" != "" ]
then
[....]

se il server mi risponde sulla porta 22 in quanto devo usare l’sftp, ma è possibile impostare la porta su di un diverso servizio esposto.
Molto versatile ed utile in quanto ha il timeout personalizzabile.

CrossCompiling ARM per C.H.I.P. 9$ computer

Per prima cosa bisogna soddisfare alcuni prerequisiti:

sudo apt-get install git ncurses-dev make gcc-arm-linux-gnueabi

git il sistema di controllo di versione del team di sviluppo del kernel
ncurses una libreria testuale usata da menuconfig
make make…
gcc-arm-linux-gnueabi il cross compiler

recuperiamo il codice sorgente del kernel che vogliamo compilare

versione kernel 4.3

git clone --single-branch --branch debian/4.3.0-ntc-4 --depth 1 https://github.com/NextThingCo/CHIP-linux.git

version kernel 4.4

git clone --single-branch --branch debian/4.4.11-ntc-1 --depth 1 https://github.com/NextThingCo/CHIP-linux.git

il comando clonerà tutto il contenuto del repository ufficiale in una directory chiamata CHIP-linux.

Il problema nasce dal contenuto di default del .config. Nel mio caso ho usato il file di configurazione di renzo:

mkdir /tmp/chiplinux4.3.0rd235+
pushd /tmp/chiplinux4.3.0rd235+
wget http://www.raspibo.org/renzo/chiplinux4.3.0rd235+.tgz
tar zxf chiplinux4.3.0rd235+.tgz
popd
cp /tmp/chiplinux4.3.0rd235+/boot/config-4.3.0rd235+ .config

A questo punto configuriamo il kernel

make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- oldconfig

eventualmente mofichiamo la configurazione con menuconfig

make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- menuconfig

e lanciamo la compilazione

make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabi- -k

sul piccolo chip servono oltre tre ore, ma con un semplice make: una volta crosscompilato, spostiamo tutta la directory /src/CHIP-linux dal computer al chip.

L’installazione si completa con

sudo make INSTALL_FW_PATH=/lib/firmware/new modules_install

CDDB

Come calcolare l’id unico che consente di ottenere le informazioni del cd da freecd o simili:

 

Assumiamo per esempio che il cd da analizzare abbia le seguenti caratteristiche:

 

# Track frame offsets:
#	150
#	15095
#	28530
#	40556
#	60479
#	81952
#	100762
#	112675
#	128656
#	145954
#
# Disc length: 2260

10 brani con lunghezza totale di 2.260 secondi: il discid di questo cd sarà 6808d20a , dove (partendo da destra) 0x0a sono i 10 brani del cd; 0x08da sono i 2.260 secondi della lunghezza del CD.

il primo valore corrisponde alla somma dei singoli numeri dell’inizio della traccia / 75… in pratica

 

ST ST/75 SUM
150 2 2
15095 201 3
28530 380 11
40556 540 9
60479 806 14
81952 1092 12
100762 1343 11
112675 1502 8
128656 1715 14
145954 1946 20
104

Il valore 104, che è la somma di tutti i valori, deve essere divisa per 255 e prendere il resto: questo in esadecimale è proprio 0x68.

 

 

Una volta che si hanno i dati del CD puoi ottenere il resto delle informazioni:

 

$ telnet freedb.freedb.org 8880
Trying 195.214.216.38...
Connected to freedb.freedb.org.
Escape character is '^]'.
201 mirror1.freedb.org CDDBP server v1.5.2PL0 ready at Wed Jul 13 16:20:36 2016
cddb hello username hostname clientname version
200 Hello and welcome username@hostname running clientname version.
CDDB QUERY  f00d0c10 16 150 20972 36331 50117 69524 86255 101371 112896 131608 138844 157390 174137 193697 208667 224774 238280 3342
200 data f00d0c10 Halsey / Badlands
CDDB READ data f00d0c10
210 data f00d0c10 CD database entry follows (until terminating `.')
# xmcd
#
# Track frame offsets:
#        150
#        20972
#        36331
#        50117
#        69524
#        86255
#        101371
#        112896
#        131608
#        138844
#        157390
#        174137
#        193697
#        208667
#        224774
#        238280
#
# Disc length: 3342 seconds
#
# Revision: 0
# Processed by: cddbd v1.5.2PL0 Copyright (c) Steve Scherf et al.
# Submitted via: ExactAudioCopyFreeDBPlugin 1.0
#
DISCID=f00d0c10
DTITLE=Halsey / Badlands
TTITLE0=Castle
TTITLE1=Hold Me Down
TTITLE2=New Americana
TTITLE3=Drive
TTITLE4=Hurricane
TTITLE5=Roman Holiday
TTITLE6=Ghost
TTITLE7=Colors
TTITLE8=Colors Pt. II
TTITLE9=Strange Love
TTITLE10=Coming Down
TTITLE11=Haunting
TTITLE12=Gasoline
TTITLE13=Control
TTITLE14=Young God
TTITLE15=I Walk The Line
EXTD=
EXTT0=
EXTT1=
EXTT2=
EXTT3=
EXTT4=
EXTT5=
EXTT6=
EXTT7=
EXTT8=
EXTT9=
EXTT10=
EXTT11=
EXTT12=
EXTT13=
EXTT14=
EXTT15=
PLAYORDER=

 

ed il gioco è fatto !!

dd con percentuale

Ho sempre voluto sapere quanto mancasse alla fine del comando dd: ecco la soluzione

utilizzando l’utente root

(pv -n /dev/sdb | dd of=/dev/sdc bs=128M conv=notrunc,noerror) 2>&1 | dialog --gauge "Running dd command (cloning), please wait..." 10 70 0

una bella barra colorata con tanto di percentuale mi tiene aggiornato.

Oracle e la scadenza della password

Come tanti utilizzo oracle per la gestione dei dati e un giorno, quasi per miracolo, sul monitor è apparsa lo slogan che mi ricordava che la password dell’utente XYZ sarebbe scaduta a breve: loggato come utente system,ho digitato

ALTER USER XYZ IDENTIFIED BY "nuovapassword";

User altered.

tutto a posto.

per rimuvere la scadenza della password:

ALTER PROFILE DEFAULT LIMIT

PASSWORD_LIFE_TIME UNLIMITED;

OpenWRT e masking IP source

Dopo che ho installato con successo OpenWRT 14.07, mi son accorto che l’IP che veniva passato al mio webserver, era mascherato con l’ip interno del modem.
Ho perso poco tempo all’inizio, ma non era fondamentale finché non ho consentito ad alcune persone di accedere al mio server… A quel punto l’esigenza di verificare da dove provenissero l’ip si è manifestata più invadente.
Ho verificato e ricontrollato la configurazione, ma l’ip sorgente delle connessioni al mio webserver risultavano sempre originata dall’ip interne del modem.
Ho deciso di mandare una mail alla mailing list do openwrt (openwrt-devel-request@lists.openwrt.org) per vedere se qualcun’altro avesse o avesse avuto il mio problema e come era riuscito a risolverlo.
A giudicare dalla risposta avuta, nessuno aveva il mio problema o non interessava a nessuno che l’ip fosse quello privato del modem.
In tutto ciò un tedesco (Lars Kruse che ringrazio immensamente per l’assist perfetto) mi dava un importante suggerimento: controllare con iptables (tramite iptables -t nat -L -vn) per verificare cosa ci fosse all’interno delle diverse chain.

la parte interessata era la zone_lan_postrouting e questa la sua versione standard:

Chain zone_lan_postrouting (1 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 postrouting_lan_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* user chain for postrouting */
    0     0 MASQUERADE  all  --  *      *       0.0.0.0/0            0.0.0.0/0           

L’anomalia è che tutto il traffico che passava per questa chain era mascherato. E secondo me non è corretto, in quanto gli ip che venivano ruotati all’interno venivano mascherati in maniera forzata.
Ho inserito all’interno del file /etc/firewall.user le righe che, secondo me, correggono il problema:

iptables -t nat -D zone_lan_postrouting -j MASQUERADE
iptables -t nat -A zone_lan_postrouting -j MASQUERADE -o pppoa-wan

la prima elimina la regola errata e la seconda maschera il solo traffico in uscita, ma non quello in entrata.

Chain zone_lan_postrouting (1 references)
pkts bytes target     prot opt in     out     source               destination
1    60 postrouting_lan_rule  all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* user chain for postrouting */
0     0 MASQUERADE  all  --  *      pppoa-wan  0.0.0.0/0            0.0.0.0/0

PS okkio : chmod +x /etc/firewall.user 🙂

Addendum:
dopo uno scambio di mail con Jow (il manteiner di firewall3, il soft che produce le regole che poi vengono passate ad iptables) ho eliminato il masq sulla zone lan->wan ed ha funzionato perfettamente il tutto.. senza addendum di script.
Jow mi ha detto che :

"Keep in mind that masq on a zone essentially masquerades all /outgoing/
traffic on that zone, so if you masq on lan then OpenWrt will set its
own lan ip in all traffic sent to lan hosts, this is almost never what
you want."

ed ora mi sono spiegato tutto..

La potenza dell’open source !!