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

sudo killall ushare

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

Avant, votre fichier de configuration était ainsi:

root@ltsp:#cat /etc/default/tftpd-hpa
#Defaults for tftpd-hpa
RUN_DAEMON="yes"
OPTIONS="-l -s /var/lib/tftpboot"

Or, maintenant, le fichier se présente ainsi:

# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS=""

Du coup, le serveur ne se lance plus (il n’apparait pas dans les processus) même si vous avez un message disant qu’il est déjà en cours de fonctionnement lorsque vous tentez de le relancer.

Il suffit alors de modifier votre fichier de la manière suivante:

# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/lib/tftpboot"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

Relancez ensuite votre serveur tftpd et vos clients devraient démarrer.

Si vous avez utilisé des outils qui paramètrent automatiquement le fichier de configuration avec l’ancienne version, réinstallez le paquet pour obtenir le nouveau fichier de configuration:

sudo apt-get install --reinstall tftpd-hpa

puis effectuez manuellement les modifications.

Mais une fois celui ci configuré, je souhaitais que GDM ne se lance plus, sauf à la demande. J’ai donc installé une version « desktop » puis j’ai cherché à désactiver GDM.

Or, si cela était évident (ou du moins connu) dans les versions précédentes, en supprimant le lien de lancement dans /etc/rc2.d ou avec update-rc.d, avec upstart c’est désormais différent.

Les programmes lancés au démarrage sont situés dans des fichiers de configuration placés dans /etc/init. Celui qui nous intéresse est gdm.conf.

Il faut modifier le fichier de la manière suivante:

de

# gdm - GNOME Display Manager
#
# The display manager service manages the X servers running on the
# system, providing login and auto-login services
 
description    "GNOME Display Manager"
author        "William Jon McCann &lt;<a class="linkification-ext" title="Linkification: mailto:mccann@jhu.edu" href="mailto:mccann@jhu.edu">mccann@jhu.edu</a>&gt;"
 
start on (filesystem
          and started dbus
          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
          or stopped udevtrigger))
stop on runlevel [016]
 
emits starting-dm
 
env XORGCONFIG=/etc/X11/xorg.conf
...

à

# gdm - GNOME Display Manager
#
# The display manager service manages the X servers running on the
# system, providing login and auto-login services
 
description    "GNOME Display Manager"
author        "William Jon McCann &lt;<a class="linkification-ext" title="Linkification: mailto:mccann@jhu.edu" href="mailto:mccann@jhu.edu">mccann@jhu.edu</a>&gt;"
 
start on []
#start on (filesystem
#          and started dbus
#          and (drm-device-added card0 PRIMARY_DEVICE_FOR_DISPLAY=1
#          or stopped udevtrigger))
stop on runlevel [016]
 
emits starting-dm
 
env XORGCONFIG=/etc/X11/xorg.conf
...

Relancer ensuite l’ordinateur, GDM ne se lancera plus au démarrage, et vous pourrez alors vous connecter sur les consoles.

Ce n’est pas une astuce exclusive, mais j’ai perdu assez de temps à chercher la réponse que je le note pour savoir où le retrouver.

Ne vous affolez pas parce que vous serez en mode texte, vous verrez qu’on arrive à faire des choses sympas ensuite.

Par exemple, vous pouvez vous identifier avec votre mot de passe et lancer la commande startx pour lancer votre environnement graphique.

Dans un prochain article, nous verrons qu’il y a mieux…

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…

Tout d’abord, lorsque vous mettez denyhosts en place sur un serveur, si vous avez une IP fixe depuis le site d’accès, pensez à vous autoriser en permanence afin de ne pas vous trouver renfermé dehors. Pour ce faire, il suffit d’ajouter la ligne suivante au fichier /etc/hosts.allow, en remplaçant les XXX par votre adresse IP fixe²:

ALL: XXX.XXX.XXX.XXX

Si vous êtes déjà enfermé dehors et que vous n’avez pas physiquement accès au serveur, il vous faut absolument changer d’adresse IP. Rebootez votre modem, ou allez chez un ami, un cybercafé ou au McDonald pour vous connecter au serveur et corriger le problème. Pensez ensuite à changer tous les mots de passe utilisés dès que vous rentrez chez vous.

Si vous avez blindé les accès au serveur et que vous n’arrivez pas à entrer, il va vous falloir être inventif. Dites vous que c’est comme ça qu’on apprend le métier et à être prudent³ . J’ai bien fait 1000 km AR en voiture juste pour re-démarrer un serveur qui avait pris un « halt » dans la mauvaise console, ce qui ne m’est plus jamais arrivé…

Mais si vous avez réussi à rentrer sur votre serveur, vous avez fait le plus gros:

1. Arrêtez denyhosts (/etc/init.d/denyhosts stop)
2. Supprimez l’entrée du fichier /etc/hosts.deny correspondant à votre IP
3. Profitez en pour ajouter votre IP au fichier /etc/hosts.allow comme indiqué plus haut
4. Allez dans le dossier /var/lib/denyhosts⁴. Vous devriez y trouver des fichiers comme ci dessous. Supprimez de ces fichiers toute occurrence à l’adresse IP concernée en supprimant complètement les lignes. la commande rgrep « xxx.xxx.xxx.xxx » /var/lib/denyhosts/ vous dira dans quels fichiers vous devez agir.
5. Relancez ensuite denyhosts (/etc/init.d/denyhosts start)
6. Envoyez moi une petite bénédiction
7. Rentrez chez vous et allez vous coucher⁵

Liste des fichiers du dossier /var/lib/denyhosts:

112253 -rw-r--r-- 1 root root 140K 2010-12-08 22:26 hosts
112142 -rw-r--r-- 1 root root 140K 2010-12-08 22:26 hosts-restricted
112251 -rw-r--r-- 1 root root 140K 2010-12-08 22:26 hosts-root
112146 -rw-r--r-- 1 root root 140K 2010-12-08 22:26 hosts-valid
112148 -rw-r--r-- 1 root root  108 2010-12-08 22:26 offset
113817 -rw-rw-rw- 1 root root  27K 2010-12-08 11:42 purge-history
112147 -rw-r--r-- 1 root root    0 2010-12-08 22:26 suspicious-logins
112143 -rw-r--r-- 1 root root  109 2010-12-08 22:26 users-hosts
112145 -rw-r--r-- 1 root root  14K 2010-12-08 22:26 users-invalid
112144 -rw-r--r-- 1 root root  118 2010-12-08 22:26 users-valid

Vérifiez quand même que l’IP n’est pas bloquée pour de bonnes raisons. Ça m’est arrivé dernièrement à cause de mauvais droits sur le home de l’utilisateur, donc le serveur SSH m’envoyait systématiquement bouler. Par conséquent, au bout d’un certain nombre d’essais échoués, denyhosts a considéré que j’étais illégitime et a blacklisté l’IP.

Je confirme avoir cherché un moment⁶.

1. parce qu’on a fait des essais, qu’on a oublié le mot de passe ou fait une erreur dans le port à utiliser…Et c’est du vécu.
2. si votre IP est variable, ça ne sert strictement à rien.
3. Il existe deux types d’administrateurs : Ceux qui ont fait une très grosse connerie en tant que root et ceux qui vont en faire une…
4. sur Ubuntu. Dans le cas d’autres distributions, cela peut varier. Il semblerais que sur certaines versions ce soit dans/usr/share/denyhosts/data/
5. c’est en général parce qu’on est fatigué qu’on fait ce type de bêtise.
6. que de souvenirs passionnant et haletants j’aurais à conter à mes petits enfants…!

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.