Back to 2000-2005: FreeBSD desktop

Tags: , ,
2 Comments »

A while ago, I had my ${DAYWORK} workstation running NetBSD, and honestly, it did pretty well. Things began to become more painful when there was no more DRI acceleration with the radeon driver, it then did an okay-ish job, but the overall desktop became somewhat laggy.
It was told someone was working on porting KMS/GEM, that was more than a year ago, and as of today, that work -and I guess it is not an easy one- isn’t mature enough to be used as a workstation, I need my desktop to run various tools, and not only terminal-based ones.
Two weeks ago, I asked for a new desktop, more powerful, so I can run more virtual machines with it. That new box was shipped with an nvidia graphic card and various modern components which I knew were not supported by NetBSD. This is one regret I have about that beautiful project, running on VAX, PlayStation 2 and Amiga is fun, but I’ll tell you a little secret: nobody cares anymore about VAX, PlayStation 2 and Amiga.
So I gave FreeBSD 10 a try. And I was not disappointed: everything, and I mean everything worked almost out-of-the-box. Of course there was a bit of fighting with the proprietary nvidia driver, but it worked as expected with 3D acceleration and all.
Not everything is perfect either, but I must say FreeBSD does a great job as a workstation, actually, it does what I needed: display a decent 2014 hardware powered desktop, no more, no less.
Under no circumstances will I replace my NetBSD servers / virtual machines (as long as they still support the underlying hardware!), they do an amazing job and I am quite happy with them, but don’t expect desktop-related commits from me to pkgsrc for the time being…

Update

Well well, this blogpost have bring much unexpected rage. Just to clarify: this is definitely not a troll or whatsoever, only an end user opinion on what’s preventing me of using NetBSD as a desktop at work for the moment.
Read the previous sentence a couple of times and notice the word “work”, the place where you can’t spend countless hours patching / tuning / trying / crashing / rebooting (sounds like a Daft Punk song) before you can reply to an urgent customer inquiry. Yes, that place. The only thing I say is: FreeBSD, as of today, does a better job at being an out-of-the-box modern desktop.
I will continue to use NetBSD as my server OS of choice, because it does rock, because it is stable, simple and fills the task perfectly. As soon as it doesn’t anymore, I’ll switch to something else, that’s what I do. Pragmatic.
So yes, I have the weakness to like shiny desktops that run something else than twm, I like transparency, I like effects when I change my virtual desktop, I like my windows to be displayed and moved rapidly, you know, pretty much like all those BSD developers that actually use OSX because it does all those things.
I will also continue contributing to pkgsrc, because it is in my optinion the most beautifull packaging system around, all I’m saying is that I won’t commit desktop-related tools I can’t really test or use. Nothing more.

Plus qu’un blog post

Tags:
3 Comments »

Ok, je vous l’accorde je poste pas des masses. MAIS ! je n’écris pas moins. Et je le prouve.
J’écris depuis plusieurs années pour le vénérable GNU/Linux Magazine France, ces articles, je les propose sous licence Creative Commons BY-NC-ND, cela signifie que 4 mois après leur parution dans le magazine, moyennant une rémunération moins importante par article, ces derniers sont publiquement et gratuitement disponibles en ligne.
Comme je ne suis pas certain d’avoir exhaustivement listé les articles disponibles ici, voici les liens directs vers les articles récents, et n’hésitez pas à vous perdre dans les milliers d’autres contributions !

D’autres sont en attente de publication, comme par exemple la serie sur Salt et Flask, stay tuned.

Bypass neufbox 6 avec NetBSD

Tags: , , , , ,
4 Comments »

Comme je l’expliquais dans le post précédent, je suis passé chez SFR/neuf avec un forfait fibre. La box de l’opérateur, la neufbox donc, ne supportant pas de mode bridgé, quelques opérations sont nécessaires à une intégration cohérente dans votre réseau domestique.

Je me suis grandement inspiré de cette excellente documentation pour réaliser le bypass de la neufbox, cependant plusieurs éléments du tutoriel ne sont plus d’actualité. Je ne rentrerai donc pas dans le détail théorique puisque l’article de neufbox4.org est parfaitement explicite, mais focaliserai sur les méthodes à mettre en œuvre pour faire rentrer votre neufbox dans votre réseau local.

Première chose, donner du lien à la nb6. Ceci est très simplement réalisé par un serveur DHCP, ISC DHCP dans mon cas, présent dans pkgsrc/net/isc-dhcpd. J’ai isolé la neufbox dans un VLAN dedié, untagged coté équipement, tagged sur mon switch. Cette opération n’est absolument pas nécessaire, mais j’aimais assez l’idée d’isoler l’équipement de l’opérateur. Après avoir ajouté le vlan dans la liste des interfaces gêrées par le serveur DHCP dans /etc/rc.conf:

isc_dhcpd_flags="vlan2 vlan3 vlan9"
isc_dhcpd=YES

On ajoute un subnet dédié :

subnet 192.168.9.0 netmask 255.255.255.0 {
        default-lease-time 3600;
        max-lease-time 3600;

        range 192.168.9.1 192.168.9.10;
        option routers 192.168.9.254;
        option domain-name-servers 192.168.9.254;
        # needed for sfr neufbox
        option nis-domain "ftth_axione_omniswitch";
        allow unknown-clients;
}

Et dans la foulée, on s’assure que la box aura toujours la même IP dans ce range :

host neufbox {
        hardware ethernet 34:85:14:85:52:27; # cette MAC est évidemment fausse
        fixed-address 192.168.9.1;
}

Une fois le port “fibre” (gris) de la box branché à votre switch, un redémarrage plus loin, les 3 leds vertes en façade devraient être allumées.

Si vous souhaitez accéder à l’interface de la neufbox, sachez qu’elle est accessible depuis le switch intégré (ports bleus) sur l’adresse IP 192.168.1.1. Ceci est modifiable via le lien http://192.168.1.1/network/lan (ce lien n’est pas présent dans le menu).

L’aspect moins simple de l’opération concerne la VoIP. Je vous renvoie à la section “réseau local” de l’article précedemment cité pour comprendre le pourquoi de ce qui suit, mais pour faire court, la box ne disposant pas de son IP publique SFR, il faut intercepter son traffic sortant vers l’infrastructure de l’opérateur, et modifier le contenu des requêtes envoyées afin d’y inclure notre IP publique.

J’ai réalisé ce tour de passe-passe sous NetBSD, à l’aide de pf et nginx. On redirige tout d’abord le traffic HTTP en provenance de la neufbox sur un port spécifique de l’interface loopback :

neufbox_if="vlan9"
# [...]
rdr pass on $neufbox_if proto tcp from 192.168.9.1 to any port 80 -> \
        127.0.0.1 port 89

Puis dans le fichier de configuration nginx, on ajoute un nouveau serveur muni d’une location / :

    server {
        listen 127.0.0.1:89;
        server_name foo *.neufbox.neuf.fr;

        access_log  /var/log/nginx/neufbox.access.log;
        error_log  /var/log/nginx/neufbox.error.log;

        resolver 127.0.0.1;

        location / {
                if ($args ~ "^ip_data=[^&]*&ip_voip=[^&]*&ip_tv=[^&]*&(.*)$") {
                        set $others $1;
                        set $nip "ip.publique.neuf"; # a modifier avec votre IP
                        rewrite /(.*) /$1?ip_data=$nip&ip_voip=$nip&ip_tv=$nip&$others? break;
                }
                proxy_redirect off;
                proxy_pass http://$host;
        }
    }

Merci à Adrien ze pour le coup de main sur la réécriture. En effet, alors que je bataillais sur le mécanisme de rewrite, ze a découvert que cette méthode de nginx ignore purement et simplement les arguments d’une URI, d’où la nécessité de passer par un ifqui match l’URL à modifier.

Un reboot de la neufbox et un tcpdump -A -ni bien placé devraient vous démontrer que la box est désormais capable de télécharger une foule d’informations la concernant, de mettre à jour son firmware et surtout, de s’informer sur les mécanismes SIP en place chez l’opérateur.

La box étant derrière un routeur et accédant à l’Internet à travers du NAT, il est utopique d’imaginer que la voix passera sans sourciller. Car si en effet la signalisation (SIP, donc) passe sans broncher (voyant allumé), si vous tentez de passer un coup de fil, vous ne recevrez ni tonalité, ni son, pas plus que vous n’en emmétrez, simplement parce que le RTP ne parvient pas jusqu’à la box.

Pour résoudre ce casse tête, plusieurs actions sont nécessaires. En premier lieu, l’installation de l’excellent serveur proxy SIP/RTP siproxd, disponible dans la plupart des systèmes de paquets. Sous NetBSD, il est présent dans pkgsrc-wip. Bon en fait il était pété, je l’ai réparé, je suis sur le point de le commit.
La configuration du logiciel est assez simple :

if_inbound  = vlan9 # interface neufbox
if_outbound = vlan8 # interface publique
sip_listen_port = 5060
daemonize = 1
user = nobody
rtp_port_low  = 7070
rtp_port_high = 7089
outbound_proxy_host = fixed.p-cscf.sfr.net
outbound_proxy_port = 5060

Afin d’autoriser le traffic RTP vers notre proxy sur les ports allant de 7070 à 7089, nous ajoutons à notre pf.conf :

# RTP / siproxd
pass in quick on $ext_if proto udp from any to any port 7069 <> 7090

L’adresse du proxy SIP fixed.p-cscf.sfr.net est fournie par la réponse à l’une des requêtes HTTP effectuées par la neufbox à son démarrage. Et justement, c’est cette adresse qu’il va nous falloir modifier pour que la neufbox interroge notre serveur siproxd plutot que ceux de SFR directement.

Dans de précédentes versions des neufbox, il suffisait de remplacer l’adresse du proxy SIP par celle désirée, mais la normalisation et plusieurs protocoles sont passés par là. Ainsi la box ne se contente-t-elle pas uniquement d’interroger un simple serveur SIP passé en argument mais réalise plutôt une requête DNS de type SRV à la recherche d’une entrée _sip._udp dans le sous domaine passé en paramètre. Cela se traduit par les lignes suivantes dans la zone DNS qui régit le réseau domestique :

$ORIGIN sip.mon.domaine.local.
@                       A       192.168.9.254
_sip._udp               SRV     10 1 5060       sip.mon.domaine.local.

192.168.9.254 est l’IP sur laquelle écoute le service siproxd.

On y est presque.

Il nous reste à modifier le contenu des informations renvoyées par l’infrastructure SFR afin de remplacer les entrées relatives au proxy sip par notre propre proxy. Ceci est à nouveau réalisé par le biais de nginx et en particulier du module sub_filter. Notez qu’il est possible que votre installation de nginx ne possède pas ce module par défaut, auquel cas il faudra recompiler ce dernier avec le flag --with-http_sub_module (oui je vais l’ajouter dans pkgsrc/www/nginx :). On modifie la configuration précédemment enregistrée :

        location / {
                if ($args ~ "^ip_data=[^&]*&ip_voip=[^&]*&ip_tv=[^&]*&(.*)$") {
                        set $others $1;
                        set $nip "ip.publique.sfr";
                        rewrite /(.*) /$1?ip_data=$nip&ip_voip=$nip&ip_tv=$nip&$others? break;
                }
                proxy_redirect off;
                proxy_pass http://$host;
                sub_filter fixed.p-cscf.sfr.net</proxy> sip.mon.domaine.local</proxy>;
                sub_filter_once off;
                sub_filter_types application/xml;
        }

Une fois de plus, on redémarre notre pauvre neufbox dont elle doit se demander ce qu’elle a bien pu faire dans une vie antérieure pour mériter ça… and voila !

Notez que les logs de siproxd affichaient un “can’t resolve ims.mnc010.mcc208.3gppnetwork.org “ qui est le realm utilisé pour l’authentification SIP, et que j’ai donc ajouté à mon /etc/hosts l’entrée suivante :

172.26.235.91   ims.mnc010.mcc208.3gppnetwork.org

car c’est l’adresse qui semblait être appelée par la neufbox en mode “direct”, mais je n’ai aucune certitude quand à l’exactitude de ce mapping. Le realm ne devrait de toutes façons être d’aucune utilité au proxy local, l’ajout statique de cette entrée n’a donc probablement d’intérêt que de m’éviter des Gigaoctets de logs.

Update Nicolas Sapa m’informe sur Twitter qu’il est parfaitement normal que l’adresse 3gpp ne soit pas resolue hors du GPRS roaming exchange, aussi serait-il probablement plus judicieux de la faire résoudre sur une adresse locale quelconque.

Vous n’êtes pas éligible à la fibre ©Free

2 Comments »

Il y a deux ans ½, je m’extasiais sur le “fibrage” de mon immeuble par Free. Naïf, je me disais à l’époque que l’Appel n’allait donc pas tarder, que le plus dur était fait, que bientôt oui bientôt, j’allais bénéficier des tuyaux de Free Infrastructure en utilisant la lumière. Naïf iMil, eternel naïf.

Régulièrement depuis cette date, j’appelle. Tous les deux ou trois mois. Et on me dit d’attendre. Que ça va plus tarder. Et j’attendais.

Et puis le mois dernier, je passe mon appel routinier, et cette fois du nouveau: “ah mon bon monsieur, votre immeuble n’est pas éligible à la fibre optique.”. Je rétorque qu’ils doivent faire erreur, qu’ils ont eux même fibré mon immeuble, ce à quoi on me répond “oui… je comprend… je répète votre demande monsieur Heitor” (oui les téléconseillers de Free ils répètent. Tout le temps.) “vous souhaitez savoir si vous êtes éligible à la fibre, et je vérifie sur mon ordinateur… voila… donc Monsieur Heitor votre immeuble n’est pas éligible à la fibre”.

Ok.

Donc, incrédule, je vais sur le site de SFR, et je rentre mon numéro de téléphone: “Bonne nouvelle ! vous êtes éligible à la fibre 1Gbps !”. Bordel cul.

Je me tâte une fois, deux fois, et j’appelle. C’était le 28 Novembre. Depuis ce matin, une fibre arrive jusqu’à mon local informatique, délivrant 300Mbps down et 50 up. Service irréprochable, les installateurs étaient très sympas, et en 1h tout était posé.

Si d’aventure un corp (placer ici une musique type “apparition divine”) Free lisait ce post, sachez qu’un tant soit peu d’information, de transparence (vous rechercherez ce mot sur le wiktionnaire) aurait probablement calmé mes ardeurs. Les miennes et celles des 4 potes qui ont fait de même.

J’étais chez Free, et finalement j’ai compris.

Le petit hint spécial NetBSD, pour se passer de la neufbox et récupérer l’IP publique en dhcp directement sur votre passerelle, créez le fichier /etc/ifconfig.iface (où iface est le nom de votre interface reliée au boitier fibre) :

up
!dhcpcd -i neufbox_NetBSD_gateway-foo@bar.org $int

Executez la commande dhcpcd précédente manuellement si vous ne souhaitez pas rebooter.

A whole new (Hello) World

Tags: , ,
1 Comment »

It’s been going on in my mind for a while, and I finally dove into Android development. As always when I put my hands on a new language / system, I had a basic need; this time I wanted to develop a simple init system that would resist my various ROMs flashing, i.e. a program that would not be located in the /system partition of the Android OS, but instead would be a package, an apk, that would read init scripts from the sdcard.

After two weeks of reading and learning Android basics, I came out with a very basic piece of code I called RcRun, which will read the content of a rc.d directory located on the primary sdcard (using Environment.getExternalStorageDirectory().toString() from java‘s Android modules) and will execute them when the BOOT_COMPLETED broadcast message is received. It will run as UID 0 using the su command (I’m using chainfire‘s SuperSU). Of course this means RcRun needs your ROM to be rooted.

There’s still a lot of work before I commit this to the official Android Market, aka Google Play, and possibly F-Droid, but RcRun is already usable for its primary goal. I run dropbear from there, plus various operations such as mounting the external’s DCIM directory on the primary sdcard DCIM.

You can fetch the apk from here and read the source code here; please be indulgent as this is my first piece of Android code ever.

ownCloud workarounds

Tags: , , ,
2 Comments »

Considering latest Google Chrome’s bugs with Tweetdeck, which I use a lot, I decided to switch back (until next time) to Mozilla Firefox. That was anyway a move I wanted to do as Google is gaining too much knowledge about me…

While restoring my various logins and passwords on Firefox, I leaned about Firefox Sync, but most of all, about the ability to run my own Sync server.

While there’s a good official documentation on how to achieve this, I heard that ownCloud has a plugin for that. And as I wanted to give that software a serious try for a couple of months, that was the way to go.

ownCloud installation is pretty straightforward, but as soon as I created the first (Admin) user, I’ve been bitten by a bug: The login screen had a redirect loop to itself. Reading many bug reports about this, I finally understood that ownCloud does not cope well with HTTP Basic Authentication. Thing is, my ownCloud instance is running as a subdirectory of a private HTTPS section of my server, protected with a password. The workaround consists in adding:

Allow from all
Satisfy Any

to ownCloud‘s .htaccess file.

Regarding sessions, do not forget to set the session.save_path variable to a directory which is writable by PHP, either apache‘s UID if you’re running mod_php or PHP-FPM‘s UID.

Another misbehavior I experienced was related to the way my website is hosted. The website you’re reading has an nginx reverse proxy in front of it, and that reverse proxy is actually an SSL termination. i.e. ownCloud has no clue it is visited using HTTPS, and that caused many glitches, especially with Mozilla Sync, which is the reason why I began all of this work.

A simple workaround consists in adding the following directive to ownCloud‘s htaccess:

SetEnv HTTPS on

in order to inform PHP that the client is actually using HTTPS.

The last bug is known and (apparently) fixed in ownCloud-6 branch: The admin panel will complain about WebDAV being broken (“Your web server is not yet properly setup to allow files synchronization because the WebDAV interface seems to be broken”), which is actually untrue, there’s a closed ticket about ownCloud behavior when behind a reverse proxy.

FYI, the ownCloud instance is running on NetBSD, and is rendered by Apache 2.4 and PHP 5.4.

WP Theme & Icons based on GlossyBlue by N.Design Studio
Banner from www.trynthlas.com
Entries RSS Comments RSS Log in
Performance Optimization WordPress Plugins by W3 EDGE