Archives mensuelles : septembre 2008

Mixer les releases Debian, sans trop de risque

4 réponses

Salut,

Il arrive qu’on ait besoin d’une application en « testing » sur un serveur en « stable ». Par exemple OCSInventory-NG. Il y a la bonne et la mauvaise méthode pour faire ça.

La mauvaise méthode (rapide, mais naze sur le long terme)

La méthode bourrin consiste à ajouter momentanément les lignes qui vont bien dans /etc/apt/sources.list, faire un apt-get update, l’installer et enlever les dépôts ensuite.
Ca marche mais on ne profite pas des mises à jour qui peuvent être importantes. Je dis ça car ensuite il vaut mieux enlever ces lignes qui risquent de vous faire migrer une partie de vos applis de « stable » à « testing » (si des fois vous êtes aveugles lors de votre « upgrade » régulier).
A ce propos, il ne faut pas oublier d’ajouter les lignes concernant le dépôt de sécurité.
Exemple, j’ajoute les lignes « lenny » pour donner ça :

deb ftp://ftp2.fr.debian.org/debian/ etch main contrib non-free
deb ftp://ftp2.fr.debian.org/debian/ lenny main contrib non-free

deb http://security.debian.org/ etch/updates main contrib non-free
deb http://security.debian.org/ lenny/updates main contrib non-free

La bonne méthode (presque aussi rapide)

La méthode propre consiste à garder tout le temps les lignes concernant les 2 (4) dépôts, mais à indiquer à APT le niveau de release que l’on veut conserver par défaut. Pour ce faire, créer un fichier du genre 00release dans /etc/apt/apt.conf.d/. Exemple :

# cat /etc/apt/apt.conf.d/00Release
APT::Default-Release "stable";

Soyez prudent les 2/3 premières fois où vous mettrez à jour vos dépôts + upgrade. Histoire d’être sûr.

Le bug qui en découle

Souvent, l’effet de bord sera ça à votre prochain « apt-get update » :

Fetched 14.6MB in 50s (292kB/s)
Reading package lists... Error!
E: Dynamic MMap ran out of room
E: Error occurred while processing tkdiff (NewVersion1)
E: Problem with MergeList /var/lib/apt/lists/debian_debian_dists_lenny_main_binary-amd64_Packages
E: The package lists or status file could not be parsed or opened.
E: Couldn't rebuild package cache

La correction sera d’augmenter un buffer quelconque pour APT, en ajoutant/adaptant, généralement dans /etc/apt/apt.conf.d/70debconf la ligne suivante :

APT::Cache-Limit 15728640; // 15 MB

Afin de repousser un peu la limite.

Voilà, c’est tout pour cette petite astuce néanmoins bien pratique.

Bip, < tab >, bip, < tab >, bip, < tab >, bip……

2 réponses

Pense-bête tout con mais ça fait tellement de bien : pour couper les p#*_ »~s de bips de votre shell ou de n’importe quelle fenêtre – je parle sous Ubuntu, allez dans Système -> Préférences -> Sons puis onglet « Bip système » et désactiver le truc qui va bien.

Je ne sais pas comment j’ai fait pour tenir si longtemps avec cette horreur.

(et avec modconf, vous pourrez virer une bonne fois le module pcspkr (« PC Speaker »), section kernerls/drivers/input/misc – yarglaaaaa)

Microsoft eOpen : toujours aussi merdique…

2 réponses

Comme ça m’arrive 2/3 fois par an, je vais sur eOpen récupérer des licences en masse de logiciels MS dûment achetés (et maintenant pour télécharger les CD car ils ne sont plus fournis).
(Pour ceux qui ne connaissent pas, eOpen est le service pour gérer tout ça)

Et comme à chaque fois, il faut :
– un clic toutes les 5 minutes tellement ça rame
– s’apercevoir que sous Firefox c’est un peu moisi ; donc recommencer la procédure sous IE
– valider 10 étapes pour dire « oui je sais c’est sensible, c’est privé, non je ne piraterai pas, oui lâchez-moi »
– enfin voir son nouveau contrat apparaitre (ouf)
– cliquer sur le bouton pour voir les numéros de licences
– revenir le lendemain et recommencer car il y a 24 heures de délai entre l’ajout et l’affichage des infos du contrat
– se dire qu’en attendant, autant lancer le téléchargement des CD, ce sera toujours ça de pris
– et une fois qu’on approche de ce Saint Graal, on obtient à chaque fois, sans mentir, ceci :

eopen ça poutre

Bon, finalement, je retenterai demain… faut pas être pressé…

Bloquer Hamachi au niveau shorewall et squid

Sympa Hamachi, j’en parlais dans un précédent billet pour l’aspect « je joue en réseau avec mes potes ».

=> Aujourd’hui, j’en parle pour bloquer cette saloperie 😉 d’outil qui peut apporter de gros ennuis au boulot 🙂

Pour rappel, c’est un VPN « zero-conf » qui permet à l’utilisateur nullissime en informatique (c’est-à-dire que vous n’avez rien besoin de connaître en info pour installer/utiliser ce truc) d’installer un VPN pour atteindre ses copains au boulot ou son PC chez lui. Au-delà de ça, ça peut rapidement se transformer en une passerelle entre un réseau bien sale (celui de l’utilisateur lambda chez lui, nul en informatique je le rappelle) et votre entreprise. D’où problèmes. D’où envie de donner des baffes.

Voici comment le bloquer (du moins maintenant il ne passe plus à mon boulot et pourtant il essaye – donc je dois avoir fait le tour de la question), tant au niveau shorewall – si l’accès Internet est direct – qu’au niveau squid si vos utilisateurs *doivent* passer par le proxy pour atteindre Internet.

Analyse à 2 balles du comportement de hamachi pour mieux le bloquer

Au départ, installez hamachi pour tester. Ca devrait se connecter sans problème. Je pense qu’il va chercher la conf proxy dans les paramètres de IE.
C’est typiquement le genre d’outils qui a prévu tout un tas de modes de connexions genre :
– essayer tout un tas de ports standards
– avoir plein de noms de machines pour atteindre le serveur par plusieurs chemins

MAIS, comme c’est un outil avec un point central (le serveur chez eux pour s’authentifier – puisque ça a une vocation commerciale, payante, tout ça), on peut à un moment donné repérer tous les serveurs centraux et les bloquer. C’est pas comme pour des protocoles décentralisés type peer-to-peer.
Bon après, s’ils changent leurs noms ou IP tout le temps, ça peut devenir pénible.

Une fois connecté, allez voir vos logs squid, vous devriez voir tout un tas de requêtes du style :

1221661590.889 350758 votre.ip.sur.lan TCP_MISS/200 3734 CONNECT ssl-24.hamachi.cc:443 - DIRECT/74.201.74.26 -

De là, avec quelques commandes hosts, genre :

for i in `seq -f '%02g' 1 40`
do
host ssl-$i.hamachi.cc
done

Ainsi que :

for i in `seq 1 255`
do
host 74.201.74.$i
done

Ce qui donne :

...
103.74.201.74.in-addr.arpa domain name pointer ns3.3amlabs.com.
104.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
105.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
106.74.201.74.in-addr.arpa domain name pointer www02-09.logmein.com.
...

Vous verrez qu’en gros, la plage IP 74.201.74.0/24 est à eux et qu’avec 4/5 noms de domaines génériques, vous pourrez tout bloquer.

Blocage niveau shorewall

En considérant que votre shorewall fonctionne bien, vous pouvez soit blacklister dans le fichier /etc/shorewall/blacklist (si vous avez bien activé l’option « blacklist » dans le fichier /etc/shorewall/interfaces), soit faire une règle dans /etc/shorewall/rules.
Dans « blacklist », ajoutez la ligne :

74.201.74.0/24

Ou, dans « rules », ajoutez :

DROP    lan     net:74.201.74.0/24      all

Relancez shorewall via /etc/init.d/shorewall reload

Blocage niveau Squid

Allez dans le fichier /etc/squid/squid.conf et à l’endroit où sont définies des « ACL », ajoutez celles-ci – c’est un exemple à adapter.

acl tout_mon_lan src 172.16.0.0/255.255.0.0
acl vilain_hamachi dstdomain .hamachi.cc .logmeinhamachi.com .logmein.com .3amlabs.com logmeinrescue.com logmeinrescue-enterprise.com
http_access deny tout_mon_lan vilain_hamachi

Ici je me base sur les noms de domaines, pas les IP. C’est un choix motivé par le fait que le client hamachi semble tenter des noms de machines, pas des IP. A voir si l’éditeur fait évoluer ça dans le temps.
Et pensez à recharger squid : /etc/init.d/squid reload

Validez que ça ne marche plus

Retestez la connexion à Hamachi. Vous devriez le voir s’exciter dans les logs squid sur quelques ssl-xx.hamachi.cc pris au hasard puis plus rien :

1221666080.309      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-14.hamachi.cc:443 - NONE/- text/html
1221666199.615      0 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-15.hamachi.cc:443 - NONE/- text/html
1221666283.816      5 votre.ip.sur.lelan TCP_DENIED/403 1441 CONNECT ssl-13.hamachi.cc:443 - NONE/- text/html

En images, ça reste sur ça :
Hamachi bloqué

Google/Chrome, admettons. Et l’OS c’est pour quand ?

20 réponses

Comme l’a très bien résumé Mr Mozilla Europe (Tristant Nitot) sur son blog, Google a tout intérêt à sortir son navigateur.

En résumé pour être plus libre et créatif dans ses services (et mieux dominer le monde ? les 2 fondateurs ont quand même parfois des idées étranges (si je ne me suis pas trompé de référence, je ne sais plus))

D’autant que vu les abonnés aux différents services Google (gmail etc), ils n’auront aucun mal à le faire répandre, contrairement à Firefox où il faut quand même chercher un peu pour l’installer (je parle des utilisateurs lambda proche du 0 en manipulation de souris – ils sont nombreux).
Là, n’importe quel utilisateur du moindre service Google pourra sûrement installer « Chrome » en un clic qui sera inmanquable sur l’interface dudit service… vous ne croyez pas ?

Bon, moi ce qui me taraude, c’est pas le navigateur, c’est l’OS. C’est pour quand ?
Qu’ils écrivent un OS depuis rien, j’en doute. C’est quand même couillu, surtout pour arriver à maturité (si la maturité d’un OS existe :). Par contre, partir d’un Linux et construire une distrib innovante, ils en ont les moyens, j’en suis sûr.
Je vois le plan d’ici : à l’install, première étape, tu donnes (ou crées) ton ID gmail et de là, ça récupère tout ton environnement OS lié à ta personne : tes applis, tes paramétrages, ton fond d’écran. Bref, tout ce que Google pourrait stocker comme ils aiment le faire.
Ca me parait réaliste :
– prendre un linux
– un système de package simple et et transparent (à la Ubuntu « ajout/suppression ») avec des applis bien senties (c’est beau d’avoir beaucoup de choix mais déroutant pour le commun des mortels à qui IE/media player suffisent puisqu’ils sont fournis)
– un look joli sans trop en faire
– évidemment un clic direct vers les services Google
Avec ça tu couvres beaucoup d’utilisateurs standards (type web/mail/mp3/msn).

Alors, votre avis ? l’OS, il viendra ? sous quelle forme ?