Le piège à con du jour : Cisco et négociation gigabit ethernet
April 22nd, 2013 by nono
Soient deux switches Cisco pleins de ports gigabit entre lesquels je veux monter un lien (en fait des liens, et un etherchannel par-dessus, mais ça n’a pas d’importance pour ce qui m’occupe). Facile, je branche, un petit no shutdown des deux côtés et c’est marre ? Ben non. Va savoir pourquoi, j’étais persuadé que la notion même de câble croisé avait disparu en gigabit ; chez Cisco, ça existe encore.
Bref, hors mdix auto, point de salut. Même en gigabit.
Tags: Cisco, grmpf
Posted in geekeries | Comments (0)
S’auto-héberger ou ne pas s’auto-héberger : telles sont les questions
April 6th, 2013 by nono
Après pas mal de lecture (et un peu d’écriture) ces derniers jours et quelques conversations ces dernières semaines, je vais essayer de mettre par écrit quelques questions à se poser à propos de l’auto-hébergement. Ne serait-ce que pour mettre un peu mes idées à plat. Je ne prétends pas apporter de réponse universelle, simplement poser une problématique.
Un point qui me semble évident mais que je préfère préciser : je me place uniquement dans un contexte personnel, ou éventuellement dans celui d’une (très) petite entreprise ; j’ose espérer que tout professionnel pour qui la présence en ligne est un peu importante s’est déjà penché sur ces questions.
À propos de technique
– Alors, l’auto-hébergement, c’est facile. Tu te montes un PC sous Linux, ou BSD si tu préfères, puis tu y installes Apache, BIND, Postfix et ejabberd, et tu configures le tout. Ensuite, tu configures ton routeur pour…
– Gné ? Kékidit ?
Comme le remarque justement Stéphane, il existe actuellement un bon paquet d’outils d’auto-hébergement «pour M et Mme Tout-le-monde» qui ont l’air intéressants mais qui ont pour principal inconvénient de ne pas être finis. De fait, aujourd’hui, ça restreint l’auto-hébergement à ceux et celles qui sont prêt(e)s à y investir un temps non-négligeable.
La plupart des composants nécessaire sont facilement disponibles, et aussi surprenant que ça puisse paraître la plupart sont relativement faciles à configurer. Typiquement, si un serveur web Apache «sorti du carton» peut demander un peu de configuration pour répondre à un besoin précis, il existe des distributions prêtes à l’emploi, tu branches et ça marche.
Ceux qui savent un peu de quoi il s’agit remarqueront immédiatement que j’ai (volontairement) choisi l’exemple simple ; l’installation d’un serveur de courrier électronique ou de discussion instantanée n’est pas si évidente que ça. Certes. Reste que l’installation de l’infrastructure nécessaire à l’hébergement d’un blog est loin d’être insurmontable. Encore une fois, l’obstacle principal est le temps à y consacrer.
Les ennuis commencent ensuite, avec la configuration du réseau. La plupart des gros fournisseurs d’accès à internet se comportent dans les faits comme des fournisseurs de télévision : l’abonné peut facilement consommer, mais doit faire pas mal d’efforts pour offrir autre chose que son temps de cerveau disponible. Ce parti-pris n’est pas dépourvu de justifications techniques, du moins dans le monde IPv4 (grosso-modo l’internet du siècle dernier) ; cependant le manque d’enthousiasme des mêmes pour le déploiement d’IPv6 ne laisse pas franchement ressentir une volonté d’évolution dans ce domaine.
C’est en ce sens que dans mon article précédent je mettais l’accent sur la formation. Ça ne veut pas dire que toute personne voulant héberger sa galerie de photos à la maison devra nécessairement devenir administrateur systèmes et réseaux, mais je reste persuadé qu’il est illusoire d’espérer pouvoir se contenter de poser une boîte derrière son Frinitel pour être visible du monde entier. Ça ne veut pas dire qu’il ne faut pas bosser sur les outils, bien au contraire ; ça veut juste dire qu’ils ne sont pas suffisants.
Les solutions ? Former l’utilisateur à l’utilisation des équipements irremplaçables (honnêtement, en dehors des unixiens à poil dur, qui a déjà joué avec l’interface de config de son Frinitel ?). Ou lui faire réaliser que les équipements en question ne le sont pas tant que ça, irremplaçables. Il existe déjà quelques ressources sur le sujet. C’est bien, mais je ne pense pas que ce soit suffisant en l’état. D’où l’idée des self-hosting parties que j’évoquais, qui permettraient au quidam intéressé d’échanger avec «ceux qui savent».
À propos de pérennité
Le point important à mon avis. Il me semble que d’une personne à l’autre on y voit des implications différentes. Pour ma part, je le dissocie complètement de la disponibilité et je m’intéresse uniquement au long terme.
Le point central : la pérennité d’une présence en ligne est liée à celle du domaine. Si votre site web change d’URL, vous perdez vos visiteurs (à moins que vous maitrisiez suffisamment l’ancienne URL pour y laisser un pointeur vers la nouvelle, que ce soit sous forme de lien ou de redirection automatique). Si votre adresse mail ou XMPP change, vos contacts ne pourront plus vous joindre.
Conclusion : vous voulez votre propre nom de domaine. Ça peut représenter une dépense, le plus souvent très faible (mes domaines me coûtent environ 5 euros par an chacun). Ça peut aussi se trouver gratuitement, le plus souvent sous forme d’un sous-domaine d’un des domaines du fournisseur ; j’hésite cependant à recommander cette option.
Dans la plupart des cas, elle nous ramène au problème de départ : le jour où le fournisseur vous jette (ou met la clé sous la porte, ou décide de faire payer le service), vous vous retrouvez le bec dans l’eau. Ça ne veut pas dire qu’il n’existe pas de fournisseurs gratuits sérieux, bien au contraire, mais il faut néanmoins en avoir conscience.
Pourtant, pour important que soit ce point, il n’est pas intimement lié à l’auto-hébergement. Certains (nombreux ?) bureaux d’enregistrement proposent en plus des prestations d’hébergement ; à défaut, il existe plein d’hébergeurs de «tout un tas de choses» qui seront ravis de vous avoir pour client même si vous n’achetez pas vos domaines chez eux. Il n’y a pas non plus de raison de ne pas héberger certains services vous-mêmes en en laissant d’autres à des professionnels grassement payés compétents ; l’essentiel est que l’utilisation de votre propre domaine rend l’hébergement invisible de l’extérieur et vous permet donc d’en changer.
C’est à mon sens le principal argument contre Google, Facebook et leurs amis : votre présence en ligne dépend uniquement de leur bon vouloir. Si, néanmoins, vous tenez absolument à dépendre d’eux, après tout, vous faites bien comme vous voulez.
À propos de données
Ça paraitra sans doute évident à qui s’est ne serait-ce que vaguement posé la question : si vos données ne sont pas chez vous, vous pouvez les perdre d’un moment à l’autre. Si vous laissez des données chez un tiers, vous devez en avoir une copie locale, ou au moins accessible quand le tiers coupera le service.
Et pas la peine de protester qu’«ils n’ont aucune raison d’arrêter leur service». Il y en a qui n’ont pas vraiment eu le choix à ce sujet.
À propos de disponibilité
Mon PC à la maison, sur le courant de la maison, au bout de l’ADSL de la maison, est moins fiable qu’un serveur hébergé dans une salle climatisée avec le courant qui va bien et des liaisons rapides et redondantes. Aucun doute là-dessus. Ceci dit, même si mes photos ne sont pas visibles pendant quelques heures, le monde ne s’arrêtera pas de tourner, n’en déplaise à mon égo. Bref, à chacun de décider si «la maison» fournit une qualité de service suffisante pour ses propres besoins.
À propos de sécurité
Un argument qui m’a l’air assez récent contre l’auto-hébergement : un serveur à la maison, c’est une machine qui risque de se faire pirater.
Sauf que non. Une machine connectée à internet risque de se faire pirater, auto-hébergement ou pas. Je ne suis pas spécialiste de la question, mais j’ai cru comprendre que la plupart des botnets étaient constitués de machines de bureau classiques, très souvent sous Windows.
Ne me faites pas dire ce que je n’ai pas dit, je ne pense pas qu’un serveur domestique soit intrinsèquement plus sûr qu’une machine de bureau. Par contre, quand Frédéric agite la menace de la police qui débarque à 6h du matin à cause d’une machine piratée, ça n’est rien d’autre que du FUD ; à supposer que le risque soit réel, il est indépendant de l’auto-hébergement. À moins que votre PC de la maison ne soit pas connecté à Internet ?
À propos de culture
Bon, au final, l’auto-hébergement, c’est déjà possible même si on peut améliorer les choses, ça demande juste un peu de connaissances et (au moins au départ) un peu de temps («un peu» étant hautement variable en fonction des ambitions de chacun). Mais alors, pourquoi est-ce vrtuellement inexistant, en dehors d’une petite tribu de barbus à poil dur ?
Une explication (trop) facile : les fournisseurs d’accès n’ont aucun intérêt à ce que ça change. Un client conscient qu’il peut parler au lieu de consommer, c’est aussi un client conscient qu’il n’est pas limité à ce que le fournisseur lui met sous le nez. C’est aussi du temps de cerveau disponible en moins.
C’est, je le concède, une vision un peu cynique, quoique probablement assez proche de la vérité dans le cas de certains vendeurs de soupe télé reconvertis dans le minitel en couleurs qui fait pouet-pouet. Pas tant parce que ce sont de méchants laveurs de cerveau, simplement c’est leur culture, à eux. Ce qui est en tout cas flagrant, par rapport aux premiers FAI que j’ai connus, c’est que les fournisseurs actuels ne font plus vraiment d’efforts d’éducation vis à vis de leurs clients. Et quand je parle de ces premiers FAI, je parle de Club Internet vers 1997 qui parlait Usenet, hébergement de sites perso (pas de connexions permanentes pour le grand public à l’époque) et netiquette, pas d’obscures associations de barbus.
Une autre explication évidente : «c’est un truc de geek», ou sa variante «c’est un métier». C’est probablement assez vrai. Comme je l’évoquais il y a quelques jours, il n’y a pas si longtemps, on avait les mêmes réactions à «un PC sous Linux à la maison». Sur ce point, je suis assez confiant : ça peut facilement évoluer dans les années qui viennent. Probablement pas au point de concerner l’ensemble ou même un quart de la population, mais assez pour être visible.
Je n’ai pas de chiffres à jour sous le coude, mais d’après ce que j’ai trouvé en quelques minutes, il y a 3 ans, la France comptait dans les 20 millions d’abonnements haut débit. Si l’auto-hébergement concernait ne serait-ce que 1% des utilisateurs, ça en représenterait déjà au moins 200 000 (probablement plus à l’heure actuelle). Assez pour se faire remarquer, assez pour que les fournisseurs d’accès fassent des efforts pour faciliter la vie à leurs clients.
À propos de rien en particulier
Ce texte est probablement un peu décousu ; c’est la première fois que j’essaie de coucher tout ça sous une forme un peu synthétique et ça demanderait probablement encore un peu de réflexion et de mise en forme.
Tags: auto-hébergement
Posted in geekeries | Comments (0)
Sur l’avenir de l’auto-hébergement
April 4th, 2013 by nono
J’avais commencé à écrire une réponse au billet de Frédéric sur l’auto-hébergement, et à force d’en ajouter je me retrouve à écrire un article complet.
Si on remplace «auto hébergement» par «une machine sous Linux à la maison» dans ce texte, on revient 10 ans en arrière. De nos jours, même si le logiciel libre n’a pas (encore) conquis le monde, avoir un PC sous Ubuntu n’a rien d’exceptionnel.
Je rejoins Frédéric sur l’importance du rôle des associations, mais plus sous l’angle de l’éducation que sous celui de l’hébergement (en gros, je penche plus pour l’approche FFDN que pour celle de l’APINC, même si on s’éloigne un peu de l’hébergement «pur»). De fait, maintenant qu’on voit apparaître des machines adaptées pour un prix accessible (je pense bien entendu au Raspberry Pi et à ses cousins, même si le Pi lui-même est encore un peu limité), je ne serais pas surpris que les années qui viennent voient fleurir des «self-hosting parties» à l’image des install parties du début des années 2000, où les «gens qui savent» prendront les novices par la main pour leur montrer que non, ça ne fait pas mal.
Car contrairement à Frédéric je suis convaincu que ça ne fait pas mal. J’héberge moi aussi à peu près tout chez moi et j’ai moi aussi connu des galères de «paf le disque» et autres ; ça existe, il suffit d’en être conscient et d’être outillé pour. Et de nos jours, être outillé pour, c’est possible et même facile, j’ai l’impression que l’obstacle est plus culturel que technique. Le seul «vrai» problème technique, c’est le relatif manque de fiabilité par rapport à un hébergement pro ; au fond, est-ce dramatique si mon blog est hors-ligne une heure de temps en temps ?
Au final, je pense qu’on est d’accord : l’auto-hébergement ne pourra pas remplacer les services hébergés par Google et ses amis, de la même façon que GNU/Linux n’a pas détrôné Windows. Ça n’en fait pas une mauvaise alternative pour autant. Je soupçonne même qu’une visibilité accrue pousserait à peu près tous les hébergeurs de services à améliorer leurs offres.
Tags: auto-hébergement
Posted in geekeries | Comments (6)
Les pièges à con du jour : Kerberos et SSH
March 13th, 2013 by nono
Aujourd’hui, deux pièges à con. 
Je commence à jouer avec Kerberos. SSH m’a posé quelques problèmes ; voilà un petit bout d’aide-mémoire pour ne pas me faire avoir une deuxième fois.
Contexte
J’ai un royame Kerberos avec deux KDC. J’ai aussi deux stations sous Debian GNU/Linux configurées pour parler aux deux KDC susmentionnés. Le tout fait tourner MIT Kerberos et c’est installé tout comme écrit dans la doc. Je ne reviens pas là-dessus, rien de bien compliqué.
Côté client
Ne pas oublier le bout de config qui va bien ; en gros, ça veut dire ça dans ~/.ssh/config :
Host * GSSAPIAuthentication yes GSSAPIDelegateCredentials yes GSSAPIKeyExchange no GSSAPITrustDns yes
On peut faire un peu plus restrictif que Host * et probablement en mettre un peu moins mais moralement c’est ça.
Côté serveur
Là, je me suis gratté la tête un moment. Si jamais Kerberos vous jette quand l’option GSSAPIStrictAcceptorCheck vaut yes et qu’il vous accepte quand l’option est à no, jetez un oeil à votre fichier /etc/hosts, cherchez-y une ligne de ce genre et enlevez-la si vous la trouvez :
127.0.0.1 mamachine.mon.domaine mamachine
La seule ligne correspondant à 127.0.0.1 dans /etc/hosts doit être celle qui définit localhost ; si vous avez autre chose, vous allez avoir des emmerdes (mon collègue de bureau appelle ça le syndrome Alain Delon).
Tags: grmpf, kerberos
Posted in geekeries | Comments (0)
Surveiller les mises à jour de WordPress
January 2nd, 2013 by nono
J’administre des serveurs qui hébergent un certain nombre de sites web sous WordPress. Comme tout WordPress qui se respecte, ceux-ci ne sont généralement pas à jour, sinon on risquerait d’avoir un minimum de sécurité, ce qui, convenez-en, ne serait pas très drôle.
J’ai donc bricolé une sonde Nagios rudimentaire pour me tenir au courant. Elle est en deux parties : un bout de script sur le serveur web, et la sonde elle-même sur le serveur de supervision.
Côté WordPress, donc, un petit script PHP qui se contente de retourner la version de WordPress installée avec un minimum de contrôle d’accès :
<?php
// Generated by /usr/local/sbin/new-wordpress
// FIXME: Should probably not be hardcoded.
if (preg_match('/^(129\.102\.6\.|2001:660:3004:6:)/', $_SERVER['REMOTE_ADDR'])) {
require_once('./wp-includes/version.php');
print($wp_version);
exit;
} else {
print('Circulez, rien a voir.');
exit;
}
?>
Bien entendu, vous remplacerez là-dedans mes adresses IP par les vôtres, sinon ça ne vous servira pas à grand chose.
L’intelligence (très modérée) se trouve côté Nagios :
#!/bin/bash
#
# Arnaud Gomes 2011
curl="/usr/bin/curl"
# WordPress API URL for determining latest version.
apiurl="http://api.wordpress.org/core/version-check/1.1/"
ok () {
echo "WORDPRESS OK - $*"
exit 0
}
warning () {
echo "WORDPRESS WARNING - $*"
exit 1
}
critical () {
echo "WORDPRESS CRITICAL - $*"
exit 2
}
unknown () {
echo "WORDPRESS UNKNOWN - $*"
exit 3
}
[ -x "$curl" ] || unknown "No CURL at $curl."
[ $# -eq 1 ] || unknown "Usage: $0 URL"
url="$1"
latest=$($curl -s "$apiurl" | tail -n1)
echo "$latest" | egrep -q '^[0-9.]+$' || unknown "Could not determine latest version."
installed=$($curl -s "$url/ircam-wp-version.php")
echo "$installed" | egrep -q '^[0-9.]+$' || critical "Could not determine installed version."
[ "$installed" = "$latest" ] && ok "Version $installed installed."
warning "Version $installed installed, should be $latest."
Et voilà, maintenant mes WordPress ne sont pas plus à jour mais je sais quand je dois râler.
Tags: Nagios, wordpress
Posted in geekeries | Comments (0)
Le piège à con du jour : entiers et booléens selon Puppet
December 21st, 2012 by nono
J’ai une config Puppet qui commence à devenir assez touffue. On y trouve entre autres un fait md_raid qui retourne le nombre de grappes RAID logicielles sur une machine Linux. Je peux donc utiliser le fait en question pour appliquer un bout de config uniquement sur les machines qui ont des grappes RAID, typiquement pour installer l’outil de surveillance qui va avec :
if $md_raid {
# bla bla bla
}
Cool, hein ? Hé non ! Pourquoi pas ? Parce que pour Puppet, tous les entiers sont vrais, même 0.
La bonne solution se trouve du côté de l’excellent module stdlib, qui fournit entre autres une fonction num2bool qui renvoie vrai uniquement pour les nombres strictements positifs. Mon test devient du coup :
if num2bool($md_raid) {
# bla bla bla
}
Cette fois, ça marche.
Tags: grmpf, puppet
Posted in geekeries | Comments (0)
Gnus et IMAP sur SSH
November 28th, 2012 by nono
Un peu de contexte pour commencer. Au boulot, mon courrier électronique est stocké sur mon PC, dans une série de boites à lettres au format Maildir, regroupées dans un répertoire appelé fort originalement ~/Maildir. À la maison, j’utilise Gnus pour lire mon courrier électronique, et je voudrais fort logiquement accéder à ces boites. Je dispose pour ça uniquement d’une connexion SSH configurée comme il faut avec les clés qui vont bien (en vrai, je pourrais avoir plus, mais ça compliquerait la config réseau).
Premier réflexe : sshfs. Ça a l’air bien sur le papier, mais ça manque sérieusement de stabilité quand il s’agit de manipuler des milliers de fichiers. À oublier donc.
Deuxième réflexe : IMAP. Dans le détail :
- J’ai installé Dovecot sur le PC du boulot.
- J’y ai posé dans mon home un fichier .dovecotrc qui contient la ligne suivante :
mail_location = maildir:~/Maildir:LAYOUT=fs
- J’ai ajouté un serveur IMAP à mon Gnus :
(nnimap "licencieux.ircam.fr" (nnimap-stream shell) (imap-shell-program "ssh gomes [chez] licencieux [point] ircam [point] fr /usr/lib/dovecot/imap -c .dovecotrc"))
Voilà, c’est tout ! J’aime ce genre d’outil simple et flexible.
Tags: emacs, mail
Posted in geekeries | Comments (0)
NRPE, root et xinetd
November 16th, 2012 by nono
Ami lecteur, si tu es, comme moi, admin système, je suis prêt à parier que tu as, comme moi, un système de monitoring que tu aimerais bien faire tomber en marche. Je m’en vais ici te donner une petite magouille toute simple qui le rendra un peu moins foireux.
La machine que je vais prendre pour illustrer mon exemple est une baie SAN (iSCSI plus précisément) qui tourne sous Scientific Linux 6. Comme toutes les autres machines de mon parc, elle fait tourner NRPE et elle est surveillée par un Nagios. Le but ici est de surveiller l’état du service tgt, qui assure la fonction de cible iSCSI.
Première étape : interroger le service depuis la machine elle-même. Ça se fait au moyen de la commande suivante :
/usr/sbin/tgtadm -C 0 --op show --mode target
Cette commande retourne la liste des cibles iSCSI définies sur la machine accompagnée d’un certain nombre d’informations à propos d’icelles (informations que j’ignorerai ici, ce n’est pas mon propos). Le premier réflexe est donc d’encapsuler cette commande dans un script shell pour en faire un greffon Nagios rudimentaire :
#!/bin/bash
ok () {
echo "TGT OK - $*"
exit 0
}
critical () {
echo "TGT CRITICAL - $*"
exit 2
}
result=$(/usr/sbin/tgtadm -C 0 --op show --mode target)
if [ $? -eq 0 ]
then
ok $(printf "$result" | egrep '^Target')
else
critical $result
fi
Rien de bien compliqué, n’est-ce pas ? Si ce n’est que l’utilisateur qui fait tourner NRPE n’aura probablement pas le droit de lancer la commande tgtadm et encore moins d’en tirer quoi que ce soit d’utile. Ou alors c’est que ton système est administré bizarrement.
Comment faire pour passer outre ? Ton premier réflexe sera probablement le même que le mien : mais c’est bien sur, y’a qu’à configurer sudo comme il faut et roule la galère. Sauf que l’idée me plait moyennement ; pas que je n’aie pas confiance en sudo, mais je sais pertinemment que je suis capable de le configurer comme il ne faudrait pas. Du coup j’ai pensé à une meilleure approche : utiliser xinetd.
Concrètement, j’ai commencé par ajouter un service dédié à sa config :
service tgtstatus
{
type = UNLISTED
disable = no
bind = 127.0.0.1
port = 11112
socket_type = stream
wait = no
user = root
server = /usr/sbin/tgtadm
server_args = -C 0 --op show --mode target
log_on_failure += USERID
}
Tu t’empresseras de me signaler que n’importe quel utilisateur local peut, du coup, voir la configuration des cibles iSCSI. Je m’empresserai de te répondre que, d’une, c’est moins grave que de pouvoir exécuter n’importe quoi à travers une config sudo qui permet de lancer un script shell pas blindé comme il faut, et de deux, que de toute façon mes baies SAN n’ont pas d’utilisateurs locaux, manquerait plus que ça.
Du coup, l’appel à tgtadm dans mon greffon Nagios est remplacé par la ligne suivante :
result=$(/usr/bin/nc 127.0.0.1 11112)
et seul le morceau du greffon pour lequel c’est absolument nécessaire est exécuté par root, sans aucun moyen de lui passer des paramètres scabreux. C’est pas beau, ça ?
En fait, ce n’est pas si beau que ça : dans l’histoire, je viens de perdre le code de retour de tgtadm (que j’ai remplacé par celui de nc, qui est, tu en conviendras, un peu moins pertinent). Pour m’en tirer, j’ai donc dû interpréter la sortie de ma commande et pas son code de retour. Du coup j’ai laissé tomber le shell pour écrire ça dans un vrai langage de programmation, en l’occurrence Python ; voilà le résultat :
#!/usr/bin/env python
# Arnaud Gomes 2012
import sys, socket, re
# Le port du service xinetd
PORT = 11112
# Codes de retour Nagios
R_OK = 0
R_WARN = 1
R_CRIT = 2
status = ''
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', PORT))
while True:
r = s.recv(1024)
if not r:
break
status += r
if not status:
print 'TGT WARNING - No targets defined'
sys.exit(R_WARN)
if re.search(re.compile('^Target [0-9]+:', re.MULTILINE), status):
output = ' '.join([re.sub('^Target [0-9]+:\s*', '', line)
for line in status.split('\n')
if re.match('^Target [0-9]+:', line)])
print 'TGT OK - Targets %s' % output
sys.exit(R_OK)
print 'TGT CRITICAL - %s' % status
sys.exit(R_CRIT)
Et cette fois-ci c’est bon, ça marche vraiment.
Tags: Nagios, système
Posted in geekeries | Comments (0)
Le piège à con du jour : /bin/bash et /bin/sh
August 3rd, 2012 by nono
Après m’être battu un petit moment contre un script de déploiement d’une appli Rails avec rvm qui foirait pour une raison inexplicable, j’ai jeté un coup d’oeil au script .rvm/scripts/rvm dans lequel j’ai trouvé ça :
# Do not allow sourcing RVM in `sh` - it's not supported # return 0 to exit from sourcing this script without breaking sh [[ ":$SHELLOPTS:" =~ ":posix:" ]] && return 0 || true
Mais /bin/sh, chez moi, c’est bash ! Et ben non, ça ne suffit pas.
Moralité : suffit de commencer le script par #!/bin/bash plutôt que par #!/bin/sh pour que mon déploiement se passe comme sur des roulettes. Portable, qu’on vous dit.
Tags: grmpf, Linux, rvm, système
Posted in geekeries | Comments (0)
Limiter les connexions par adresse IP : mauvaise idée
May 16th, 2012 by nono
Je gère depuis un petit moment un serveur de miroirs relativement important accessible, entre autres, via FTP et HTTP. Vu l’amour immodéré que je porte à cette relique du siècle dernier qu’est FTP, j’ai limité les ressources qu’il peut consommer pour favoriser HTTP. Entre autres, j’ai choisi de limiter le nombre de connexions simultanées à deux par adresse IP, et tant pis pour les amoureux de NAT qui devraient rejoindre ceux de FTP dans leurs 20 ans de retard.
Sauf que ça casse l’accès FTP non seulement pour les boîtes NAT, mais aussi pour l’outil de monitoring du miroir Apache, qui pour une raison ou une autre ouvre plusieurs connexions simultanément. Mauvaise idée, donc.
Grmpf.
Tags: grmpf, NAT, réseau, système
Posted in geekeries | Comments (0)