Gcc 5.2.0 on Odroid XU3

This is old, don’t think I’ll ever need it again, but better visible than hidden forever.

Was not easy to find what I need to compile GCC 5.2.0 on this board, so for those who need it ..

To fix this bug :

In file included from /usr/include/stdio.h:27:0,
 from ../.././libgcc/../gcc/tsystem.h:87,
 from ../.././libgcc/libgcc2.c:27:
/usr/include/features.h:374:25: fatal error: sys/cdefs.h: No such file or directory
compilation terminated.

I had to install one of these (I installed all to avoid any surprises…shame on me…)

apt-get install libc6-dev libc6-dev-arm64-cross libc6-dev-armel libc6-dev-armel-cross: libc6-dev-armhf-cross libnewlib-dev

To avoid nasty errors like that :
In file included from ./bconfig.h:3:0,
 from ../.././gcc/genmddeps.c:18:
./auto-host.h:2188:16: error: declaration does not declare anything [-fpermissive]
 #define rlim_t long
 ^

You may want to configure gcc with a minimal number of language :

./configure  --enable-languages=c,c++

And for me it way enough.

Things about SSH that I always forget…

As usual, this article is for me to remember, if you like it good for you.

Sources:

How to use certificate instead of password when connecting to SSH

First make sure you have a certificate ready to go otherwise, create one (something like ssh-keygen).

ls .ssh/
id_rsa id_rsa.pub known_hosts

On the server, just copy past the content of id_rsa.pub, in a file called ~/.ssh/authorized_keys.

cat id_rsa.pub >> ~/.ssh/authorized_keys

How to connect to a SSH server via another ssh server (sort of tunnelling)

Step one, Tunnel

The command first:

ssh -L 127.0.0.1:8080:BACKSERVER:8080 -N USERID@FRONTSERVER

– L LOCALIP:LOCALPORT:DISTANTIP:DISTANTPORT

-N : dont start the bash.

Step two, Automagic configuration

The SSH client has a wonderful configuration file that might be empty for most of us, however when correctly configured … it can save you so much time!

So, let see my ~/.ssh/config file.

Host jump_server
User my_user_name_on_the_jump_server
Hostname DNS_OR_IP_OF_JUMP_SERVER

Host internal_server
User my_user_name_on_the_internal_server
Hostname DNS_OR_IP_OF_INTERNAL_SERVER
Port 22
ProxyCommand ssh -q -W %h:%p jump_server

With this configuration, when I do ssh jump_server, I directly ssh to the jump server. If I do ssh internal_server, I directly ssh to the internal server. If all these server have my public ssh key, then no password login, never ever …

How to browse the web through this tunnel

A nice thing is that we can do Dynamic Port Forwarding with SOCKS proxy in one command now.

ssh -D 9000 internal_server

This command will open a SOCKS proxy at 9000, directly working with firefox.

 

Installing Apache Spark on Fedora

This article is mostly inspired from existing blog posts:

As usual this is here for myself mostly. If you found that helpful good for you.

1) Download the most recent archive from https://spark.apache.org/downloads.html

wget https://downloads.apache.org/spark/spark-2.4.5/spark-2.4.5-bin-hadoop2.7.tgz

2) Extract the archive in /opt/spark/

cd /opt/sudo tar xzf spark-2.4.5-bin-hadoop2.7.tgzsudo
ln -s /opt/spark-2.4.5-bin-hadoop2.7/ /opt/spark

3) Add the spark user

sudo useradd spark
sudo chown -R spark:spark /opt/spark*

3) Restoring context for SELinux (instead of naively turning off of SELinux…)

sudo restorecon -rv /opt/spark*

4) Prepare two systemd script to start master and slave services and run them

/etc/systemd/system/spark-master.service

[Unit]
Description=Apache Spark Master
After=network.target

[Service]
Type=forking
User=spark
Group=spark
ExecStart=/opt/spark/sbin/start-master.sh
ExecStop=/opt/spark/sbin/stop-master.sh

[Install]
WantedBy=multi-user.target

/etc/systemd/system/spark-slave.service

[Unit]
Description=Apache Spark Slave
After=network.target

[Service]
Type=forking
User=spark
Group=spark
ExecStart=/opt/spark/sbin/start-slave.sh spark://X.Y.Z.A:7077
ExecStop=/opt/spark/sbin/stop-slave.sh

[Install]
WantedBy=multi-user.target

We can now reload the scripts and run the service.

sudo systemctl daemon-reload
sudo systemctl start spark-master.service
sudo systemctl start spark-slave.service

5) The server is ready, however now, instead of turning off the firewall, please update it.

The most basic way would be something like that:

sudo iptables -I INPUT 1 -i eno1 -p tcp --dport 8080 -j ACCEPT
sudo iptables -I INPUT 1 -i eno1 -p tcp --dport 8081 -j ACCEPT
sudo iptables -I INPUT 1 -i eno1 -p tcp --dport 7077 -j ACCEPT

If you cannot connect to the server (no name server for example) you can enforce IP to listen to.

sudo cp /opt/spark-2.4.5-bin-hadoop2.7/conf/spark-env.sh.template /opt/spark-2.4.5-bin-hadoop2.7/conf/spark-env.sh

Then using the following variables in spark-env.sh

export SPARK_MASTER_IP=X.Y.Z.A export SPARK_MASTER_HOST=X.Y.Z.A

Voila!

Linux modules and secured boot

So this post is in two steps, first how to build a linux module, then how to install a module when you are using secured boot environement.

Build a Linux module

You can have a simple module by writing a C file module.c such as :

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>


int finit(void)
{
printk(KERN_INFO "Start module\n");

return 0;
}


void fexit(void) {
printk(KERN_INFO "Stop module\n");
}


module_init( finit );
module_exit( fexit );

Compilation is then as easy as this Makefile :

obj-m += module.o
all:
      make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
      make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

You can then load and unload this module using insmod and rmmod. However, if you have a secured boot setup, things get a little bit more complicated.

Load a module in a secured boot environment

This time, we will need to sign modules and declare the key we used to sign modules as a reliable key.

First we generate keys:

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -nodes -days 36500 -subj "/CN=NAMEHERE/"

then we use the key to sign the module:

sudo /usr/src/kernels/$(uname -r)/scripts/sign-file sha256 ./MOK.priv ./MOK.der simple.ko

We also need to declare the key a reliable, at the next boot of the machine, the firmware will ask if this key is OK:

sudo mokutil --import MOK.der 
reboot

And voila!

Sources :   https://github.com/greggagne/osc10e/tree/master/ch2 and https://stegard.net/2016/10/virtualbox-secure-boot-ubuntu-fail/

 

Building a compiler with Crosstool-ng

What is crosstool-ng : http://www.crosstool-ng.org/

Step 1 – Preparation

Download and compile it :

$  git clone git://crosstool-ng.org/crosstool-ng
$  cd crosstool-ng
$  ./configure --enable-local 
$  make

Step 2 – Configuration

Configure your target (ex: arm architecture) :

$ ./ct-ng arm-unknown-linux-gnueabi

If you are not sure about the target you need, you can check the existing ones :

$ ./ct-ng list-samples
....
[L..] armeb-unknown-linux-gnueabi
....
[L..] x86_64-unknown-linux-gnu
[L..] x86_64-unknown-linux-uclibc
[L.X] x86_64-w64-mingw32
[L..] xtensa-unknown-linux-uclibc
 L (Local) : sample was found in current directory
 G (Global) : sample was installed with crosstool-NG
 X (EXPERIMENTAL): sample may use EXPERIMENTAL features
 B (BROKEN) : sample is currently broken

Step 3 – Generation

Generate the compiler :

$ ./ct-ng build

Usage

Once the compilation is done,

$ export PATH=crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools/bin/:$PATH
$ export CCPREFIX := arm-unknown-linux-gnueabi-
$ export AS := $(CCPREFIX)as
$ export LD := $(CCPREFIX)ld
$ export CC := $(CCPREFIX)gcc
$ export AR := $(CCPREFIX)ar

You can also repeat the build operation on different target to generate all you need:

$ ./ct-ng arm-unknown-linux-gnueabi 
$ ./ct-ng build
$ export PATH=crosstool-ng/.build/arm-unknown-linux-gnueabi/buildtools/bin/:$PATH

Possible errors

[ERROR] g++-4.6.real: internal compiler error: Killed (program cc1plus)

This happended to me on a board with not enough memory. You can temporarily add more swap :

dd if=/dev/zero of=swap.img bs=1024k count=1000
mkswap swap.img
swapon swap.img

Sources

Building embedded ARM systems with Crosstool-NG

[F15] Ajouter un raccourci personnalisé sous gnome 3

Comme vous le savez, gnome3 est assez .. épuré … en terme de paramétrage rapide. Et pour cause, le mot d’ordre semble avoir été de privilégier l’usage au paramétrage (ce qui ma foi est plutôt une bonne chose).

Du coup, voilà une manière propre d’ajouter un raccourci personnalisé dans la liste des applications favorites.

Pour cela il faut ajouter un nouveau fichier .desktop dans le dossier share/applications, cependant contrairement à ce que certains conseillent, je suis totalement opposé à l’écriture dans le dossier /usr/share/aplications, et pour cause, chaque utilisateur dispose de son propre dossier : ~/.local/share/applications (à créer s’il n’existe pas encore).

Par exemple, pour ajouter un lien vers eclipse avec les arguments qui vont bien :

mkdir -p ~/.local/share/applications
cp /usr/share/applications/eclipse.desktop ~/.local/share/applications

Puis modifier le fichier eclipse.desktop comme bon vous semble :

[Desktop Entry]
Type=Application
Name=Eclipse superstack
Comment=Eclipse Integrated Development Environment
Icon=eclipse
Exec=eclipse -vmargs -Xms1024m -Xmx4196m
Terminal=false
Categories=Development;IDE;Java;

Ensuite il suffit de réactualiser la liste des applications, pour cela on redémarre gnome3 :
[alt] + [F2], tapez « r » puis [enter]

Et voilà votre nouveau raccourci « eclipse superstack » est ajouté à la liste des applications disponibles.

Gnome3 : quelques astuces

Je viens de me mettre à gnome3, j’en bave un peu pour retrouver mes marques.

Du coup je vais poster ici ce qui m’a vraiment bloqué pour l’instant :

Afficher la date de l’horloge : gsettings set org.gnome.shell.clock show-date true
Afficher les numéros de semaine dans le calendrier : gsettings set org.gnome.shell.calendar show-weekdate true
Ajouter les boutons minimize et maximize des fenêtres : gconftool-2 –set /desktop/gnome/shell/windows/button_layout –type string « :minimize,maximize,close »

Utiliser la touche [Del] pour supprimer dans nautilus :

1) Activer le mode de modification des raccourcis : gsettings set org.gnome.desktop.interface can-change-accels true

2) Puis aller dans Fichier > edition > Mettre à la poubelle (sans cliquer) et faire [Del] [Del] , le raccourci est modifié.

3) Désactiver le mode : gsettings set org.gnome.desktop.interface can-change-accels false

et dans le même genre : https://bodman.wordpress.com/2011/08/01/ajouter-un-rac…se-sous-gnome3/

Voilà, c’est tout pour l’instant.

Sources : http://www.khattam.info/howto-add-minimize-maximizerestore-buttons-in-gnome-3-2011-05-26.html, http://www.khattam.info/howto-enable-delete-key-in-nautilus-3-fedora-15-2011-06-01.html

Valgrind with C++ on fedora 14

Si vous aussi, vous aviez une erreur lors de l’utilisation de valgrind avec fedora 14 en C++, réjouissez vous, la solution existe (et elle est  bien simple).

en root :
>yum reinstall libstdc++ libstdc++-devel gcc-c++ gcc
>ldconfig

Cela dit, j’ai observé un problème assez gênant, je dois refaire la manip après chaque reboot de la machine….

Ayant lu en diagonale le lien suivant, je n’ai pas encore obtenu solution finale, mais c’est déjà bien.

source: https://bugzilla.redhat.com/show_bug.cgi?id=650149

Faire ses propres RPMs sous Fedora

Bonjour à tous,
Cela fait bien longtemps que je voulais faire ce ticket. A chaque fois que j’ai une manipulation à faire sur un RPM c’est la même rengaine, c’est une action rare et du coup je dois bien passer deux heures à chercher pour faire une action qui devrait prendre 3 minutes.

Les RPM, et le packaging en général sont des sujets très intéressants, très documentés aussi. Je citerais mes sources en fin d’article.

Étape 1 – Préparation logiciel

Alors voici un certains nombre d’applications à installer pour être bien préparé :

(En root)
yum groupinstall "Fedora Packager"
yum install rpmdevtools
yum groupinstall "Development Tools"
yum install kernel-devel kernel-headers kmodtool fedpkg (pour les amoureux du noyau et des modules)

Etape 2 – Utilisateur builder

Bon je l’appel builder (je sors ça d’un tutos) mais prenez le nom que vous voulez.

(En root)
useradd builder
passwd builder
su - builder
rpmdev-setuptree

echo "%vendor                    VOTRE_NOM" >>    $HOME/.rpmmacros
echo "%packager             Fedora user" >>    $HOME/.rpmmacros
echo "%dist                       .f14" >>    $HOME/.rpmmacros

(Pensez bien sur à remplacer VOTRE_NOM et f14 pour les valeurs de votre choix)

Etape 2bis (facultative) – Préparation des signatures GPG

A la suite de l’étape 2, faites :

gpg --gen-key
echo "%_signature             gpg" >>    $HOME/.rpmmacros
echo "%_gpg_name              VOTRE_NOM" >>    $HOME/.rpmmacros
echo "%_gpg_path              /home/builder/.gnupg" >>    $HOME/.rpmmacros
gpg --export --armor >RPM-GPG-KEY-VOTRE_NOM

Etape 3 – Construction d’un RPM

Alors ici, plusieurs possibilités, voici donc une liste de quelques opérations courantes :

  • Construction d’un paquet déjà existant sur un dépôt distant
  • Construction d’un paquet à partir d’un src.rpm
  • Construction d’un paquet à partir du fichier SPEC

Construction d’un paquet déjà existant sur un dépôt distant

C’est le cas le plus simple et le plus courant. Par exemple, mettons qu’il y ait une erreur de dépendance entre deux paquets suite à la mise à jour de l’un sans recompilation de l’autre, la solution est de compiler à nouveau le paquet défectueux.

Parfois cette erreur n’est corrigée sur les serveurs que plusieurs jours après. Un solution serait alors de les devancer sans pour autant avoir à compiler à la main le dernier tar.gz qui traine.

Pour cela, rien de plus simple,  il suffit de récupérer le fichier src.rpm sur le dépôt distant directement avec yum :

(En builder)
cd ~/rpmbuild/SRPMS
yumdownloader --source mpd

Désormais le fichier src.rpm se trouve dans le dossier courant (~/rpmbuild/SRPMS) lisez la suite pour préparer le rpm.

Construction d’un paquet à partir d’un src.rpm

Une fois le fichier src.rpm copié dans le dossier rpmbuild/SRPMS de l’utilisateur builder :

(En builder)
rpmbuild --rebuild mpd-0.15.11-1.fc14.src.rpm

Et voila, le dossier rpmbuild/RPMS/x86_64 (ou i586, selon l’architecture de la machine local) contient le rpm désiré.

Si vous souhaitez préciser l’architecture ciblée, faite ainsi :

rpmbuild --rebuild mpd-0.15.11-1.fc14.src.rpm --target i586,x86_64

Si vous souhaitez pouvoir modifier ce paquet (ajouter un patch ou je ne sais quoi, lisez la suite).

Construction d’un paquet à partir du fichier SPEC

La préparation de paquet à partir d’un fichier SPEC est très fréquente aussi. Qu’il s’agisse d’une nouvelle application (donc absente des dépôts distants) ou bien d’une mise à jour. C’est le moyen de modifier des paquets déjà existants.

Pour ce faire, vos sources (le tar.gz ainsi que les patchs)  doivent être présentes dans le dossier ~/rpmbuild/SOURCES et votre fichier spec dans le dossier rpmbuild/SPECS.

Si vous disposez d’un src.rpm, utilisez la commande suivante :

(En builder)
rpm -ivh mpd-0.15.11-1.fc14.src.rpm

Si vous ne disposez que d’un fichier SPEC, il existe une commande qui, si les liens du spec sont corrects, vous permettra de rapatrier tous  les fichiers nécessaires.

(En builder)
cd ~/rpmbuild/SOURCES
spectool -g ../mpd.spec

Ensuite la construction se fait ainsi :

(En builder)
cd ~/rpmbuild/SPECS
rpmbuild -ba mpd.spec

A la fin de ces étapes, vous disposez enfin de rpm valides dans le dossier ~/rpmbuild/RPMS.

Pour les installer, une solution simple s’offre à vous :

(En root)
rpm -ivh  /home/builder/rpmbuild/RPMS/i386/mpd-0.15.11-1.fc14.i386.rpm

Mais une deuxième solution existe, le dépôt local.

REMARQUE : La compilation d’un RPM nécessite les dépendances de ce dernier. Pour les installer facilement :

yum-builddep less-394-1.fc4.src.rpm -y

 

Création d’un dépôt local pour yum

Préparation

Pour construire son propre dépôt il faut commencer par ranger les rpms dans un dossier commun. Ici j’utiliserais /DATA/depot/14.

On respectera l’arbo (RPM et SRPMS) déjà utilisée pour le dossier rpmbuild de l’utilisateur builder.

[FACULTATIF] Signer les paquets (avec builder)  rpmsign –addsign paquet.rpm [FACULTATIF]

Pour générer le dépôt, rien de plus simple :

(utilisateur gérant le dossier /DATA/depot/14)
cd /DATA/depot/14
createrepo .

Un dossier repodata est créé, tout s’est bien passé.

Définition du dépôt local dans yum

La définition du dépôt local se fait dans le dossier /etc/yum.repos.d/

Ajoutez-y un fichier local.repo contant les lignes suivantes :

[localrepo]
name=Fedora Core $releasever - My Local Repo
baseurl=file:///DATA/14
enabled=1
gpgcheck=0

mettez gpgcheck=1 si vos paquet sont signez, mais pensez alors à installer la clef GPG :

(En root)
rpm --import ~builder/RPM-GPG-KEY-VOTRENOM

A chaque modification du dépôt, pensez à refaire la commande createrepo. De même, pour vous assurer que ces nouveaux paquets soient pris en compte par yum, pensez a faire un yum clean metadata.

Voilà, c’est tout pour aujourd’hui.

Sources :

http://doc.fedora-fr.org/wiki/RPM_:_environnement_de_construction (mon ticket est très inspiré de cette page)

http://www.g-loaded.eu/2005/12/11/local-yum-repository/ (Partie dépôt local)