Dans tous les cas, vous pouvez lancez la commande suivante avant de relancer ushare:

sudo killall ushare

Les derniers pilotes Athéros ne sont pas disponibles. Le serveur semble down ou cassé, mais il est possible d’installer les drivers pour faire fonctionner cette carte réseau grâce à un forum allemand.

Installons d’abord les éléments nécessaires

sudo apt-get install --reinstall linux-headers-$(uname -r) build-essential

Nous allons ensuite installer DKMS pour installer le module

sudo apt-get install --reinstall linux-headers-$(uname -r) build-essential dkms        # s'ils ne sont pas déjà installés
## Pour Ubuntu 10.04
wget http://media.cdn.ubuntu-de.org/forum/attachments/2666793/AR81Family-linux-v1.0.1.14_dkms.tar.gz
sudo tar xvf AR81Family-linux-v1.0.1.14_dkms.tar.gz -C /usr/src
 
# Pour Ubuntu 10.10 et supérieur
wget http://media.cdn.ubuntu-de.org/forum/attachments/2666793/AR81Family-linux-v1.0.1.14_10.10.tar.gz
sudo tar xvf AR81Family-linux-v1.0.1.14_10.10.tar.gz -C /usr/src

Création du module et installation

sudo dkms add -m atl1e -v 1.0.1.14
sudo dkms build -m atl1e -v 1.0.1.14
sudo dkms install -m atl1e -v 1.0.1.14

Chargement du module et test

sudo modprobe atl1e
dmesg | egrep 'atl1e|eth'
ifconfig -a

Malheureusement, l’archive pour 10.10 et supérieurs n’est plus disponible sur ce site. Je met donc au moins l’archive pour 10.04 à disposition sur le mien au cas où elle disparaitrait

AR81Family-linux-v1.0.1.14_dkms.tar

Source: http://forum.ubuntuusers.de/topic/lan-geht-nicht-wlan-schon/#post-2666793

Cette astuce fonctionne peut être avec les versions suivantes, mais je ne l’ai pas testée. A confirmer.

Si vous avez besoin d’utiliser XDMCP sur votre réseau, vous constaterez qu’avec la « nouvelle » version de GDM, il n’est plus possible de l’activer facilement¹.

Or, il suffit de quelques manipulations pour la remettre en place.

Paramétrer le serveur XDMCP

Tout d’abord, il faut créer le fichier /etc/gdm/custom.conf qui va enregistrer les options de GDM, et en particulier celles concernant XDMCP.

Remplissez le avec ceci:

[daemon]
 User=gdm
 Group=gdm
[security]
 DisallowTCP=true
[xdmcp]
 Enable=true
 DisplaysPerHost=2
 HonorIndirect=false
 MaxPending=4
 MaxSessions=16
 MaxWait=30
 MaxWaitIndirect=30
 PingIntervalSeconds=60
 Port=177
[greeter]
[chooser]
 Multicast=false
[debug]
 Enable=false

Il suffit ensuite de redémarrer le service GDM pour activer le XDMCP.

service gdm restart

Cependant, si vous avez désactivé IPV6 sur votre réseau, cela ne fonctionnera pas, puisque XDMCP écoute par défaut en IPV6 désormais. Vous pouvez le voir en root avec la commande netstat:

root@test4:/home/manu# netstat -putan|grep 177
udp6       0      0 :::177        :::*        646/gdm-binary

Il faut alors désactiver IPV6 sur l’ordinateur qui diffusera son affichage, par exemple en le désactivant au niveau du noyau.

On peut le faire en rajoutant une option au fichier de configuration de grub. Modifiez les fichier /etc/default/grub pour ajouter l’option « ipv6.disable=1″

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"

Reconstruisez le fichier de configuration de grub par « sudo update-grub » puis redémarrez votre ordinateur. Netstat vous indique alors que XDMCP écoute en IPV4²

root@test4:/home/manu# netstat -putan|grep 177
udp       0      0 0.0.0.0:177        0.0.0.0*        658/gdm-binary

Utiliser le client XDMCP

On peut utiliser Xming depuis Windows, mais depuis Linux, il est plus simple d’utiliser tsclient. Dans la liste des protocoles, si vous ne voyez pas XDMCP, c’est qu’il vous faut l’installer le paquet xnest

sudo apt-get install xnest

Ensuite, pour la connexion, c’est du classique.

Un client XDMCP en console

Si vous désirez lancer une session XDMCP systématiquement, il est inutile se charger gnome ou un gestionnaire de fenêtres simplement pour lancer tsclient puis votre session XDMCP. Il est possible de lancer celle ci directement.

Désactivez le lancement de GDM, puis logguez vous sur l’ordinateur et tapez la commande suivante:

/usr/X11R6/bin/X -query 192.168.1.2

où 192.168.1.2 est le serveur sur lequel vous avez activé XDMCP.

Sources:

• http://doc.ubuntu-fr.org/tutoriel/comment_creer_un_terminal_x_ou_recycler_une_vieille_machine?s=xdmcp
• http://ubuntuforums.org/showthread.php?t=1471703

1. en tout cas, pas aussi facilement qu’avant
2. notez le 6 qui a disparu et la notation des adresses

virtualbox

J’ai eu un problème étrange avec un Windows XP pro lancé dans Virtualbox, et j’ai suffisamment cherché pour mettre la solution ici au cas où d’autres rencontreraient le même souci.

Ce windows fonctionnait très correctement jusqu’à ce que je change la machine physique sur laquelle il tournait dans Virtualbox. Sur le nouvel ordinateur, plus puissant et plus « gonflé » en RAM, windows arrivait à l’écran d’identification puis rebootait immédiatement. Ou se figeait.

Une autre image de windows fonctionnait, elle, correctement. Par contre, celle ci ne demandait pas à l’utilisateur de s’identifier, on arrivait directement sur le bureau.

Après avoir modifié le mode de connexion, le même problème que pour la première image se présentait.

Pour les deux images, le mode sans échec fonctionnait et me permettait d’accéder au système.

J’ai donc essayé de modifier le mode d’identification afin que l’ouverture soit automatique (et profiter d’une définition plus grande permettant d’afficher les fenêtres dans leur totalité), mais impossible. Une fois que l’utilisateur devait s’identifier, le problème apparaissait et impossible de revenir en arrière.

Et trouver des infos sur le net avec ces symptômes, c’est mission impossible, vu que des pannes de windows, il y en a plein qui donnent le même résultat…

J’ai donc été modifier l’option indiquant à windows de ne pas redémarrer en cas d’échec afin d’avoir l’écran bleu permettant d’avoir quelques informations supplémentaires (clic droit sur le poste de travail, Propriétés, Onglet Avancé, Démarrage et récupération -> Paramètres, puis décocher redémarrer automatiquement)

Et le BSOD m’a indiqué un problème avec Intelppm.

BSOD intelppm

Une recherche sur le net m’a conduit sur la page d’un blog msdn qui dit:

Dans certaines circonstances avec un système d’exploitation Windows XP / 2003 – intelppm.sys et processor.sys peuvent bloquer une machine virtuelle fonctionnant sous Virtual PC / Virtual Server (ce qui invite le système d’exploitation Windows invité à redémarrer automatiquement – mais si vous avez modifié ce paramètre, vous verrez un écran bleu). La raison de ce crash est que ces pilotes tentent d’effectuer une opération non gérée à l’intérieur de la machine virtuelle (comme la mise à niveau du microcode des processeurs physiques, en changeant l’état d’alimentation du processeur physique).
Aujourd’hui, ce problème se produit uniquement sur les Centrino et processeurs AMD K8. La plupart des gens voient ce problème quand ils déplacent une machine virtuelle qui a été créé sur un autre type de processeur pour un ordinateur exécutant l’un de ces types de processeurs…

Ça parle de Virtual Server (de Microsoft), mais avec Virtualbox, c’est la même chose. Ça provient donc d’un problème de Windows. Et le problème peut se produire avec Processor, pas seulement Intelppm.

La solution est simple:

Si vous voyez ce problème à plusieurs reprises vous pouvez désactiver manuellement ces pilotes (avec aucun effet secondaire négatif) en allant à l’emplacement suivant dans le Registre:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Processor
Ou
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Intelppm
et changer la valeur de ‘Start’ à 4.

Dans le même temps nous avons fait quelques changements subtils à la façon dont notre matériel expose le processeur dans Virtual Server R2 de sorte que dans les futurs produits, ces pilotes ne devraient jamais être chargés à l’intérieur des machines virtuelles.

Ouf, je suis rassuré! Virtual Server ne sera plus bloqué par ce comportement, mais peut être que Virtualbox continuera à l’être. Donc, ça peut toujours servir de connaitre le truc pour s’en sortir.

Sources:

• http://blogs.msdn.com/b/virtual_pc_guy/archive/2005/10/24/484461.aspx
• http://kernelreloaded.blog385.com/index.php/archives/virtualbox-bsod/

Mais quand on se trouve sur une machine qui n’a pas d’interface graphique, ou par SSH ?
Effectivement, on peut s’en sortir à grand coup de du, grep et find .

Par exemple, et vous conviendrez que c’est facile à mémoriser :

du -cks * | sort -rn | while read size fname; do for unit in k M G T P E Z Y; do if [ $size -lt 1024 ]; then echo -e  « ${size}${unit}\t${fname} »; break; fi; size=$((size/1024)); done; done.

Mais il n’est pas du tout pratique de se construire une représentation de l’arborescence pour agir efficacement et rapidement.

Confronté à un manque surprenant de place sur un NAS distant venant à peine d’être installé (500 Go / 1 mois), j’ai recherché un outil me permettant de trouver quel utilisateur squattait la place.

NCDU, pour NCurses Disk Usage, permet d’analyser le système de fichier, en tout cas l’arborescence dans laquelle vous vous trouvez ou celle que vous lui indiquez, et de naviguer dedans. Et de supprimer les fichiers/dossiers inutiles que vous rencontreriez.

Dans mon cas, supprimer le dossier de films de vacances² d’un utilisateur a permis de retrouver de quoi travailler confortablement pour les autres.

NCDU se trouve dans les dépôts officiels, et un simple sudo apt-get install ncdu vous permettra de profiter de ce formidable cli tool.

1. L’équivalent pour windows est WinDirStat
2. mouais…

Du coup, j’ai écrit rapidement un petit programme python qui fait la conversion (ldif2vcf.py) d’un carnet d’adresses rapidement, puisque je n’ai pas trouvé de solution sur le net¹.

Comme il est destiné à Roundcube et que celui ci n’utilise pas (pour l’instant) tous les champs disponibles dans une vcard, seules sont converties les informations de nom, prénom, nom à afficher et adresse mail principale. Par conséquent, si vous voulez l’utiliser pour autre chose, ne vous étonnez pas si toutes les informations ne sont pas récupérées dans le fichier de sortie².

Le fonctionnement est simple: vous indiquez le fichier d’entrée (.ldif) avec l’option « -f » et le fichier de sortie (.vcf) avec l’option « -o« . Si vous n’indiquez pas de fichier de sortie, le résultat s’affiche à l’écran.

Il faut bien sûr exporter préalablement votre carnet d’adresses depuis Thunderbird quelque part sur votre ordinateur.

exemple:

python ldif2vcf.py -f /tmp/adresses_personnelles.ldif

ou

python ldif2vcf.py -f /tmp/adresses_personnelles.ldif -o /tmp/sortie.vcf

L’option « -h » affiche une aide succincte.

1. vive les formats ouverts!
2. mais la modification de code serait simple pour tout récupérer

La première chose à faire est de vous assurer que le serveur réponde bien en HTTPS et non en HTTP, et de faire un GET:


telnet 82.XXX.XXX.XXX 443
Trying 82.XXX.XXX.XXX...
Connected to 82.XXX.XXX.XXX.
Escape character is '^]'.
GET /
<html>
<body>

<h1>It works !</h1>
<br />
</body>
</html>
Connection closed by foreign host.

Si vous obtenez du code html, comme c’est le cas ci dessus , au lieu d’une bouillie de caractères (ou de …rien), c’est que vous n’êtes pas en HTTPS mais en HTTP tout court.
Or, comme firefox s’attend à recevoir un certificat dont la longueur est faible, mais qu’il reçoit le code html complet d’une page, forcément il dit que c’est trop long.

Ce qui se trouve confirmé par la lecture du fichier /var/log/apache2/error.log:
[Sat Oct 09 14:40:18 2010] [error] [client 10.0.0.1] Invalid method in request \x16\x03
qui dit que la méthode d’accès n’est pas la bonne.

C’est pas très parlant, mais vu que j’ai galéré pour trouvé d’où venait le problème, j’essaye d’en faire profiter les autres.

Ah, au fait! Mon problème venait que dans la conf de mon virtualhost en SSL je mettais l’IP publique, vu que c’est le seul serveur en DMZ et que tout renvoie dessus. Je croyais le firewall transparent, vis à vis d’apache.
Je me trompais. Il faut mettre l’IP sur le réseau local, vu par la carte réseau elle même.
Après, ça va tout de suite mieux.

1. à noter qu’Opera donne un autre type d’erreur, mais que je ne l’ai pas notée (erreur fatale 550, si ma mémoire est bonne)

« La connexion au « controluser » tel que défini dans votre configuration a échoué.« 

Comme je passe de la hardy vers la jaunty (LTS to LTS) pendant le déplacement, je me suis dit que quelques différences pouvaient exister et afficher ce message d’erreur qui ne m’empêchait pas de me connecter à phpmyadmin.

Puis je me suis souvenu que pendant l’installation de ce programme, il m’avait demandé plusieurs fois la configuration de MySql sans arriver à s’y connecter. Et dans le speed de la migration, j’ai oublié de vérifier que ça fonctionnait correctement, vu que j’arrivais à me connecter. Et que les principales opérations étaient effectuées en ligne de commande.

Après une recherche un peu plus poussée dans le code des fichiers de phpmyadmin, je me suis rendu compte qu’il cherchait à utiliser l’utilisateur phpmyadmin. Utilisateur visible dans les privilèges de l’ancien serveur, mais pas sur les privilèges du nouveau.

J’ai donc créé un nouvel utilisateur nommé « phpmyadmin » pour le serveur « localhost »¹ avec le mot de passe permettant tous les privilèges, à savoir celui de root, et j’ai donné un droit d’usage simple, non Grant.

Il parait que lancer sudo dpkg-reconfigure phpmyadmin peut résoudre le problème, mais cela n’a pas fonctionné dans mon cas, au contraire de la création manuelle de l’utilisateur.

Classé dans la catégorie « ça a fonctionné pour moi ».

1. très important: « localhost », pas autre chose

Je viens de reconstater l’erreur sur deux ordinateurs strictement identiques (seuls les numéros de série changent), installés l’un après l’autre avec le même disque d’installation.

Sur l’un des systèmes, pas de problème. Sur l’autre, des erreurs non flagrantes apparaissent:

A l’installation d’un programme lançant un service, il apparait une erreur de ce type:

...
Paramétrage de cups-pdf (2.5.0-12) ...
   * Reloading Common Unix Printing System: cupsd                        [fail]

Quand on relance manuellement le service, on a ceci:

#service ssh restart
exec: 129: restart: not found

C’est bien sûr la même chose avec stop, restart, …

Après beaucoup de recherches, j’avais trouvé que c’était un problème dû à udev. Je ne me souviens plus de la raison donnée à l’époque.

Comme le problème vient de m’arriver de nouveau, je vous donne la solution, au cas où vous vous trouveriez dans le même cas: il faut réinstaller udev et redémarrer l’ordinateur (facultatif, mais préférable pour que tous les services soient lancés dans l’ordre prévu)

sudo apt-get install --reinstall udev
sudo apt-get install --reinstall upstart

Je dis que ce n’est pas flagrant, parce que la première fois, j’ai livré l’ordinateur sans constater de dysfonctionnement à l’usage. Alors que j’avais testé le fonctionnement général, comme à chaque fois. C’est le fait de devoir relancer manuellement cups à chaque fois pour pouvoir imprimer qui a révélé le problème.

Aujourd’hui, je ne me fais plus avoir.

Du fait du peu d’utilisation de ces processeurs, ou de leur utilisation très spécifique, les développeurs se concentraient (ou migraient) vers les versions x86. Cette décision fait suite à une réflexion lancée sur le sujet par un développeur de Canonical, Scott James Remnant.

Donc, à partir d’Ubuntu 10.10, le caractère multi plateforme de la distribution sera moins universel. Cependant, Ubuntu continuera de ne pas être seulement présente uniquement  sur les processeurs x86, puisque les processeurs ARM, équipant entre autres les tablettes et les terminaux mobiles, intéresse les développeurs pour les applications mobiles et embarquées.

Rappelons que les processeurs ARM possèdent une faible consommation électrique, ce qui fait qu’on les trouve principalement dans les systèmes embarqués, mais le fondeur Marvell a annoncé la sortie de processeurs gravés en 40 nm destinés à des serveurs simples tels des serveurs web sur ARM. Or, à l’époque des économies imposées et du déficit énergétique de la terre, je pense que diviser la consommation électrique des datacenters par 5 risque d’en intéresser plus d’un, google le premier. Actuellement, seul le vieillissant windows CE fonctionne sur cette architecture, et un dirigeant de Microsoft a annoncé que Windows 7 ne gèrera pas les processeurs ARM. Une opportunité à saisir pour GNU/Linux, même si je reste persuadé qu’une réaction de Microsoft se fera sentir dès que ce marché ne sera plus un marché de niche.

Espérons que l’abandon d’une architecture profitera aux autres.

En effet, rien n’empêche le propriétaire du point d’accès de surveiller tous les échanges sur cette borne, ou un pirate de sniffer les communications.

Il est possible d’utiliser votre serveur qui tourne à la maison, (voire même un serveur kimsufi, dédibox, ou autre), comme relai pour vos communication, à la fois pour la navigation web et pour les mails. L’important étant que vous ayez confiance dans la machine qui va vous servir d’intermédiaire et du réseau sur lequel elle est connectée.

L’avantage, c’est que c’est rapide et simple à mettre en place, même au dernier moment.

Précisions

Un tunnel ssh ne permet de passer que des protocoles basés sur TCP, au contraire d’un VPN qui permet de transporter tout type de trame IP et non IP en plus d’apporter un routage complet. Ce n’est donc pas un VPN au sens réel du terme, mais cela va vous permettre d’utiliser la sécurité du SSH sur la partie du réseau qui n’est pas fiable.

Creusons le tunnel

Votre ordinateur relai devra, bien évidemment, avoir un serveur SSH accessible depuis l’extérieur. L’idéal étant de pouvoir s’y connecter par clef plutôt que par mot de passe, ce qui vous permettra de fermer l’authentification par clef et de limiter les attaques. Mais les deux fonctionnent.

Je vous laisser lire la documentation pour mettre en place un serveur ssh si vous ne savez pas encore le faire.

Nous allons donc lancer une connexion vers notre serveur, et « binder » (lier) cette connexion à un port local afin que tout ce qui arrive sur le port local soit transféré sur la connexion SSH (et vice versa). Dans un terminal, qu’il faudra laisser ouvert tout le temps de la session, entrez ceci:

ssh -D 1234 utilisateur@serveur_relai

Un man ssh vous donnera plus de détails sur le fait que l’option -D fait que SSH se comporte comme un serveur SOCKS et vous rappellera que seul root peut utiliser les ports privilégiés. Nous utilisons arbitrairement le port 1234, mais vous pouvez utiliser n’importe quel port local supérieur à 1024 (lancé par un utilisateur non root) à condition qu’un service ne tourne pas déjà sur ce port.

Si votre serveur ssh ne tournait pas sur le port par défaut, vous pourrez alors utiliser cette commande en précisant le port de votre serveur:

ssh -D 1234:port_ssh utilisateur@serveur_relai

par exemple

ssh -D 1234:443 utilisateur@serveur_relai

ou

ssh -D 1234 -p 443 utilisateur@serveur_relai

Si vous fermez le terminal dans lequel vous avez ouvert le tunnel, la communication serait fermée et vos logiciels ne pourraient plus sortir. Il faudra donc ne pas le fermer tout le temps de la session.

Hey Ho, Hey Ho, on rentre … dans le tunnel

Maintenant que nous avons créé notre tunnel, il faut indiquer aux logiciels de l’utiliser.

Par exemple, pour firefox:

menu Édition > Préférences > Avancé > Réseau > Paramètres

Utilisez un proxy SOCKS qui est donc votre ordinateur (point de départ de la connexion SSH) sur le port indiqué (1234 dans ce cas) tel que ci dessous

Pour vous convaincre que vous passez par votre serveur et non par la connexion wifi en cours, allez visiter un site comme http://www.monip.org/ qui vous montrera votre adresse IP externe. Si votre serveur a une IP fixe, vous reconnaitrez facilement votre IP. Sinon, visitez le site, un coup sans proxy, un coup avec, et vous verrez que l’ip n’est pas la même.

Par exemple, pour thunderbird:

Les avantages de cette solution, pour envoyer du mail, sont:

• vous n’aurez pas à modifier le serveur SMTP d’envoi à chaque fois, même si des extentions existent pour compenser ce problème.
• pas d’interception de vos mails par un éventuel proxy ou sniffer sur le réseau
• l’adresse IP d’expédition est celle de votre serveur, pas celle de votre emplacement actuel (vie privée respectée)

Rendez vous à menu Édition > Préférences > Avancé > Réseau et espace disque > Paramètres et paramétrez tel que sur l’image suivante:

Lorsque vous enverrez un mail, il passera par le tunnel et sera donc réellement envoyé par votre serveur relai vers votre propre fournisseur d’accès, indépendamment du FAI depuis lequel vous êtes actuellement connecté.

Pour les autres logiciels:

Le principe du paramétrage est identique aux exemples ci dessus. Cherchez dans leur configuration comment utiliser un proxy socks.

Ça peut aussi ne pas fonctionner!

En effet, si un proxy est paramétré sur votre réseau (pas chez vous, là où vous êtes connecté) et qu’il ne laisse pas passer le ssh, vous êtes bloqué. Mais il existe parfois des solutions:

• Si le blocage du ssh est dû aux ports qui sont autorisés, il vous faudra mettre votre serveur ssh (chez vous) en écoute sur un de ceux ci. Il y a de fortes chances pour que le http et le https soient autorisés (sinon le proxy ne servirait à rien, autant débrancher le câble…).
• Si le blocage est dû à l’analyse des flux par le proxy et que le ssh est refusé, il faudra passer par un tunnel http dans lequel vous ferez passer un tunnel ssh (ou ce que vous voudrez). Vous pouvez utiliser l’excellent http-tunnel qui vous sortira de l’impasse.
• Si le proxy utilise un filtrage applicatif en plus du reste… c’est que l’admin est un acharné et que vous n’arriverez pas à sortir par cette voie.

Notez qu’il est possible de faire la même chose avec putty et Windows mais je vous laisser faire ça seuls, n’ayant plus de licence depuis longtemps, et encore moins l’envie de me salir les mains avec ça.

A lire aussi:

• http://proxytunnel.sourceforge.net/paper.php
• http://forum.ubuntu-fr.org/viewtopic.php?id=213500