Ce post s’adresse principalement aux admins qui se servent de l’interface WHM/cPanel.

Si vous MODIFIEZ une entrée de type « A » pour un sous-domaine dans une zone DNS, et bien WHM n’ajustera pas automatiquement la config d’Apache si celle-ci contient déjà des blocks « virtualhost » associés à ce sous-domaine.

On doit aller modifier à la mitaine (old school way, yay!) la conf d’Apache pour ajuster les IP « bindés » aux sous-domaines.

* TOUJOURS FAIRE UN BACKUP AVANT *

Ensuite, pour vous assurer que les ajustements de la config seront pris en charge lors de futures modifications automatiques de celle-ci par WHM/cPanel, vous devez exécuter cette commande :

/usr/local/cpanel/bin/apache_conf_distiller --update

Pour vérifier que tout est OK, exécuter cette dernière commande :

/usr/local/cpanel/bin/build_apache_conf

Et finalement, ouvrez de nouveau la conf d’Apache et valider que les changements sont restés.

Version utilisée : WHM 11.26.20 sur Fedora 7 i686

Sur ce, bonne administration!

Voici un petit tutoriel qui va servir à plusieurs. Il existe beaucoup de tutoriels qui explique comment limiter les accès à un dossier avec Apache mais très peu pour limiter à un accès à un fichier. Pour cela, on a besoin d’un fichier .htaccess et d’un fichier .htpasswd tout comme pour protéger un dossier.

Créer le fichier .htaccess

Il doit être enregistré dans le dossier contenant le fichier à protéger par mot de passe.

<Files fichier-a-proteger.txt>
 AuthUserFile [chemin_absolu].htpasswd
 AuthGroupFile /dev/null
 AuthName [texte]
 AuthType Basic
 <Limit GET POST>
   require valid-user
 </Limit>
</Files>

• [chemin_absolu] : chemin sur le serveur (à modifier lors de la mise en ligne)
• [texte] : texte qui sera affiché dans la fenêtre pour se connecter

NOTE : il faut répéter le bloc <Files> ci-dessous pour chaque fichier que l’on veut protéger.

Créer le fichier .htpasswd

Ce fichier doit être enregistré à l’emplacement définit dans le fichier .htaccess. Il contient les couples identifiant:mot_de_passe. Il peut être édité à la main.

franck:t3stmdp!
thomas:Dur%Pwd

Pour ajouter encore plus de sécuriser, il est possible d’encrypter les mots de passe en MD5 ou en SHA.Voici les lignes de commandes à utiliser :

• en MD5 : htpasswd -m .htpasswd [nom_utilisateur]
• en SHA : htpasswd -s .htpasswd [nom_utilisateur]

La ligne de commande va demander deux fois le mot de passe. Après, vous pourrez ainsi trouver une ligne similaire dans le fichier .htpasswd.

john:$apr1$l250XlpJ$N5MhahpljP3gxHcxeMjY8.

NOTE : cette même ligne de commande permet de mettre à jour un mot de passe pour un utilisateur déjà existant.

Problème :

Que faire si on a plus que 9 arguments à gérer dans une règle de réécriture ?

Solution :

On peut utiliser l’instruction RewriteMap avec le paramètre prg, qui lui apelle un script Perl.

Exemple :

Contenu du fichier .htaccess :

RewriteMap manyargs prg:/home/projet/splitargs.pl

RewriteEngine On

RewriteRule ^/blog/(.*)$ /blog.php?$(manyargs:$1) [PT]

Contenu du fichier splitargs.pl :

#!/usr/bin/perl

$|=1

my $i=0;

my @args = split !/!, $_;

foreach my $args (@args) {

  $i++;

  $return .= "&arg$i=$arg";

}

$return =~ s/^&//;

print $return

Discussion :

Cette règle permettra un nombre indéfini d’arguments d’apparaître dans l’URL et générera une requête avec ces arguments nommés séquentiellement.

Cela peut s’avérer très utile dans le cas ou on a plus de 9 arguments à traiter. Le traitement des expressions régulières dans mod_rewrite est limité à 9 arguments tout simplement parce que le 10e argument ($10) serait indifférentiable du 1er ($1) suivi d’un « 0″.

Je trouve étrange qu’on soit limité de la sorte… selon moi il aurait pu y avoir un moyen d’échapper les arguments à 2 chiffres. Mais bon, avec l’instruction RewriteMap et un simple script Perl, il est possible de pallier cette limitation!

Ubisoft a présenté il y a environ un mois un nouveau système DRM. En résumé, un DRM(Digital Rights Management) est un système qui permet de vérifier que le jeu ou l’application ne sont pas une copie. Ces systèmes permettent en théorie de réduire le taux de piratage, mais en pratique, ils amènent beaucoup de problèmes chez les clients.

Certains DRM étaient tellement restrictifs que beaucoup de clients qui avaient acheté des jeux légalement étant incapable de jouer avec leurs jeux nouvellement achetés. Le système avait des failles ou n’avait pas été testé assidument sur tous les systèmes d’exploitation. Un des systèmes qui avait été pointé particulièrement du doigt était Starforce parce qu’il simulait un lecteur CD-ROM pour faire ses tests de vérifications. Le lecteur CD-ROM virtuel est venu entrer en conflit avec certains lecteurs CD-ROM bien réel et rendait ces lecteurs complètement inutilisables. Le gamer devait donc tout simplement réinstaller Windows afin de pouvoir utiliser son lecteur. Le système a été piraté assez rapidement, au point tel que certaines personnes qui avaient acheté le jeu le pirataient afin d’éviter des problèmes.

Le nouveau système de Ubisoft a décidé de s’y prendre d’une autre façon. Plutôt que d’installer des trucs bizarres et qui vont peut-être entrer en conflit avec certains ordinateurs, ils ont décidé d’obliger l’utilisateur d’avoir une connexion sur internet s’il voulait jouer. Le jeu utilisant ce DRM ferait des vérifications périodiquement pendant que vous jouez (dans le jargon, on appelle ça Phoning home). Ubisoft a poussé la chose un peu plus loin en gardant sur leur serveur votre partie enregistrée.

Voici les principaux points négatifs soulevés :

• Vous devez toujours être en ligne… en d’autres mots, si votre connexion internet flanche, vous perdez votre progression dans le jeu.
  L’implémentation du jeu ici est cruciale. Les développeurs pourraient forcer le jeu à se fermer et vous perdriez votre progression, ou ils pourraient simplement vous donner un avertissement en attendant que votre connexion internet revienne. Vous pourriez perdre votre connexion à cause de votre ISP (Bell, Vidéotron, etc.) à cause de votre rooter ou simplement à cause d’un câble qui s’est fait manger par votre chien.
• Il deviendrait impossible de revendre votre jeu. Le jeu serait associé à votre compte Ubisoft, vous seriez donc obligé de vendre votre compte Ubisoft aussi, ce qui est impossible selon la condition d’utilisation (TOS) des comptes Ubisoft.
• Si les serveurs d’Ubisoft sont fermés pour réparation ou pour une mise à niveau, vous serez dans l’impossibilité de jouer, parce que les parties enregistrées sont sur leur serveur et l’authentification est impossible à faire.
• Possiblité de jouer sans CD/DVD, qui était le DRM par défaut de plusieurs jeux.

Les bons côtés maintenant :

• Si tout fonctionne, on pourrait rêver à une diminution du prix des jeux parce qu’il y aurait moins de piratage, mais j’imagine que le prix va rester le même et les profits seront redistribués sur d’autres franchises et le développement de nouveaux jeux.
• Possiblité de jouer chez un ami avec votre personnage sans avoir à amené votre partie enregistrée. Le fait d’avoir votre partie sur leurs serveurs vous permet de jouer de n’importe ou, pourvu que le jeu soit installé. En théorie c’est une bonne idée, mais en pratique, si vous allez chez ami, c’est pas pour qu’il vous regarde jouer et si vous le faites, vous amenez votre ordinateur. Pourtant, Ubisoft met l’emphase sur ce « très » bon côté.
• Possiblité d’avoir des amis et de parler avec eux pendant que vous jouer, un peu comme fait Steam ou Battle.net entre autres.

En en parlant avec Guillaume, nous avons trouvé des bons côtés qui malheureusement, n’ont pas été mentionnés par Ubisoft pour l’instant :

• Des marchants légendaires se promenant de joueur en joueur et vendant les items achetés/vendus par les autres joueurs. Nous aurions de vrais marchands itinérants!
• Des troupes ennemies légendaires se promenant aussi de joueur en joueur. Présentement les ennemis sont gérés au hasard ou reviennent toutes les X minutes.
• Rendre possible de switcher entre le jeu single player et multiplayer plus facilement et avec plus de transparence. Je vois particulièrement l’intérêt ici, vous êtes en train de jouer avec vos amis et tout à coup votre petit frère commence à télécharger un film en HD sur sa Xbox360, il serait possible de tomber en mode single player et continuer à jouer où vous étiez rendu. Le système d’authentification et d’enregistrement de partie demande beaucoup moins de bande passante qu’un jeu complètement en ligne.
• Avoir les bons cotés des MMO sans avoir les mauvais cotés : Système de vente aux enchères sans les serveurs trop lents par exemple.
• Avoir des émissaires ou des factions qui se promènent entre les joueurs, selon les missions accomplies et les choix faits par les joueurs, le monde diplomatique et ou physique du jeu pourrait changer. Par exemple, 60% des gens décident d’aider le scientifique fou et une ville complète disparaît de la carte pour tous les joueurs. Une ville se fait conquérir par le royaume ennemi parce que la majorité des joueurs ont décidé d’aider le royaume.

Beaucoup de bonnes (et mauvaises!) idées peuvent ressortir avec un système qui oblige le joueur à avoir une connexion internet constante. Les implémentations de ces exemples se font au niveau du jeu et non pas au niveau du DRM, mais si le DRM oblige l’utilisateur à être connecté, les implémentations deviennent beaucoup plus faciles à réaliser. Personnellement, j’espère que le système fonctionnera et qu’il profitera des ouvertures qu’il apporte, mais j’ai bien peur que beaucoup de pirates s’amuseront à faire planter les serveurs de Ubisoft pour les obliger à le retirer. Si les serveurs ne tiennent pas le coup devant les pirates, les gens vont commencer à poursuivre Ubisoft parce que les biens qu’ils ont achetés sont inutilisables.

Une newsletter est destinée à plusieurs boites de messagerie différentes (hotmail, yahoo, gmail, outlook, thunderbird…) et chacune réagit différemment. La simplicité et l’accessibilité est de mise! Voici quelques règles à suivre pour maximiser la compatibilité:

- Ne pas excéder 600 pixels de large

- Ne pas dépasser 30 Ko

- Insérer le code à l’intérieur de la balise BODY (oublier le reste)

- Intégrer complètement en tableaux (aucun div!)

- Déclarer le CSS à l’interieur du code (CSS inline)

- Lier toutes les images (et autres médias) en liens absolus

- Utiliser les entités HTML

- Valider le code (Validator du W3C)

- Supprimer les espaces inutiles et les commentaires

Conseils éclairs

Il semble y avoir des problèmes de compatibilité avec la couleur de background déclaré dans le HTML, BODY ou un DIV. Je vous recommande donc de créer un tableau 100% avec un BGCOLOR.

Il semble aussi avoir des troubles avec les BORDER dans hotmail. Vous pouvez toujours créer des bordures artificielles à l’aide de TR et TD en spécifiant une couleur de fond et un width ou un height.

Privilégiez les IMG au lieu des BACKGROUND-IMAGE. Vous constaterez que hotmail et outlook sont capricieux sur ce point.

Quelques liens très utiles sur le sujet :
http://www.email-standards.org/
http://www.campaignmonitor.com/css/
http://www.xavierfrenette.com/articles/css-support-in-webmail/