Armetiz

SELinux est installé et activé par défaut sur les installations CentOS 6.

Pour mettre en place une infrastructure Web éclatée, j’ai choisis de mettre en place un serveur NFS qui héberge les fichiers de mes applications PHP.
Les serveurs Apache sont donc configurés comme des clients NFS, et le DocumentRoot point vers le point de montage NFS.

Au démarrage d’Apache :
Warning: DocumentRoot [/var/www/tld.domain/subdomains/foo/httpdocs] does not exist

Ce problème peut-être causé par un défault de configuration de SELinux,
Pour vérifier on désactive SELinux et on relance Apache.

setenforce Permissive
service httpd restart

Si Apache démarre correctement, c’est donc bien une configuration SELinux qui bloque.
Il faut modifier un booléen SELinux : httpd_use_nfs qui est à « off » par défaut.

setsebool httpd_use_nfs on

Cela fonctionnera aussi apres un reboot de votre serveur.

Cette article fait suite à une incapacité technique de ma part à comprendre les comportements concernant le fonctionnement du domaine d’application.

Voici l’énoncer du problème, nous avons deux fichiers SWF présents sur deux domaines différents.
Nous souhaitons simplement pouvoir utiliser une librairie partagée entre ces deux SWF et donc utiliser des définitions de classes communes.
L’objectif est donc d’utiliser un seul domaine d’application pour les deux SWF.

D’après la méthode officielle,

var _loader : Loader = new Loader ();
var _request : URLRequest = new URLRequest ( "http://www.example.com/foo.swf");
var _context : ContextLoader = new ContextLoader ();
 
_context.applicationDomain = ApplicationDomain.currentDomain;
 
_loader.load ( _request, _context );

Le problème a été retourné dans tout les sens.. nous n’avons jamais eu les mêmes domaines d’applications pour l’enfant et le parent.

De plus, il est simple de vérifier si deux SWF utilise le même domaine d’application.

trace ( String ( __loader.contentLoaderInfo.applicationDomain == ApplicationDomain.currentDomain ) ) ;
//false systématiquement

Les crossdomain sont présents sur les deux serveurs, et les utilisations de Security.allowDomain (« * »); n’ont pas été oubliées.

Aussi, le soucis reste le même lorsque nous travaillons en local et que l’on charge le SWF avec un chemin relatif.
Ce qui est étrange, c’est que dans ce cas les définitions de classes sont utilisables et donne l’impression d’un seul domaine d’application.

Du coups, j’y perds totalement mon latin. A savoir que nous avons tester avec le player 10.2.152 et 10.1

Les distributions Debian utilisant un Kernel inférieur à la version 2.36 sont touchées par ce problème.

Parce que SNMPD n’est pas lancé avec l’utilisateur Root, celui-ci n’est pas capable de connaitre la vitesse réelle des interfaces réseaux.
Voici le résultat que l’on obtient après une requête SNMP.

IF-MIB::ifSpeed.1 = Gauge32: 10000000
IF-MIB::ifSpeed.2 = Gauge32: 10000000

D’après SNMP, nous avons donc affaire à des cartes 10Mbps, or il s’agit de carte 100Mbps.

Ce bug est identifié #609226 chez Debian.

Afin d’obtenir la bonne vitesse de vos cartes réseaux, soit vous attendez que le Kernel 2.36 soit intégré à Debian soit vous appliquez le patch et re-compiler un noyaux.

Voici le fichier diff contenant le patch :

Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
 
 
diff --git a/net/core/ethtool.c b/net/core/ethtool.c
index d2c4da5..970eb98 100644
--- a/net/core/ethtool.c
+++ b/net/core/ethtool.c
@@ -1423,6 +1423,7 @@ int dev_ethtool(struct net *net, struct ifreq *ifr)
 
 	/* Allow some commands to be done by anyone */
 	switch (ethcmd) {
+	case ETHTOOL_GSET:
 	case ETHTOOL_GDRVINFO:
 	case ETHTOOL_GMSGLVL:
 	case ETHTOOL_GCOALESCE:

L’article a été mis à jours le 14 Avril 2010.

Si vous recherchez une entreprise de maintenance informatique proposant des services de qualité pour un faible coût, je vous conseille de contacter Turnaway.fr.

Lorsque l’on allume son ordinateur équipé de Windows 7, il arrive que l’on ne puisse pas accéder à Internet alors que tout les autres ordinateurs fonctionnent parfaitement.
Les configurations réseaux sont fournies par un serveur DHCP correctement configuré et testé depuis longtemps.

Les syndromes

Des messages : Réseau non identifié ou Pas d’accès Internet

Ce qui est étrange sur le screenshot ci-dessus, c’est qu’il existe deux « réseaux » sur une seule connexion physique alors qu’il s’agit d’une configuration réseau standard.

L’explication

L’explication se situe au niveau de la table de routage IPv4.

En effet, nous remarquons à travers la table de routage qu’il existe deux routes par défaut. A la limite, cela peut arriver, mais avec une métrique identique cela risque de ne pas fonctionner correctement.

La solution 1 – Temporaire

Voici la solution que j’utilise :
Supprimer les routes par défaut; avec un Invité de commande lancé avec les droits d’administrateur :

route DELETE 0.0.0.0

relancer la découverte DHCP

ipconfig /renew

La solution 2 – Permanente

A ceux qui ont le problème, avez-vous un logiciel Adobe ? Comme Photoshop CS3 ou Flash CS3 ? Si oui, nous avons trouver le fautif !
Adobe CS3 installe un logiciel de découverte réseau basé sur le protocole Bonjour de Apple. Celui-ci lui permet de trouver les serveurs Version Cue qui sont à proximités.

Pour plus d’information sur l’utilisation de Bonjour par Adobe CS3, voici une TechNote en anglais.

Le logiciel est installé sous forme de service ce qui nous permet de le désactiver simplement.

Pour désactiver le service :

• Aller dans le gestionnaire de service : services.msc
• Clique droit sur « la chose » qui commence par ##Id_String1….##, allez dans les propriétés
• Pour Type de démarrage, sélectionner Désactivé

En redémarrant votre ordinateur, vous ne devriez plus avoir le problème.

Nous pouvons signifier que le problème ne touche que les utilisateurs de Adobe CS3 et Windows 7.
Cela s’explique par une implémentation différente de Bonjour au sein de Adobe CS4 et supérieur.

Suite à une commande de carte de visite chez vistaPrint, j’ai reçu un mail pour me confirmer son envoi.

Voici un extrait de ce mail :

Récapitulatif de l’expédition de votre commande :
Votre commande arrivera au plus tard le: 08/05/2009
Numéro de commande : 18071-06611-2S2
Date de la commande : 26/04/2009
Votre commande arrivera au plus tard le: Lent

Options de livraison: 21 Jours
Votre commande arrivera au plus tard le: 17/05/2009

Donc, pour résumer, ma commande arrivera au plus tard le 08 Mai 2009, mais aussi le Lent, et pour finir le 17 Mai 2009.
Vous savez quelle date c’est « lent » ?

Mise en situation :

• Migration d’un parc informatique d’un domaine LYON qui n’existe plus
• Un domaine de niveau fonctionnel 2000 mixte au FDQN : formation.local
• Un serveur DNS intégré à Active Directory et configuré lors du DCPROMO
• Un parc informatique assez homogène avec des clients Windows XP

Le problème :

Nous passons l’ensemble des postes sous FORMATION. Et nous rencontrons un problème à partir du troisième poste “Erreur lors d’une tentative de jonction au domaine FORMATION”. Certains postes fonctionnent et d’autres non.

Solutions potentielles

Après moult vérifications et tentatives, rien n’y fait, jusqu’au moment où « Victoire ! »
Voici le résultat de nos recherches, et donc les points qui sont à vérifier si vous rencontrez ce problème.

• Si le nom de l’ordinateur est présent dans « Computers » sur l’AD, supprimez le. Théoriquement cela ne pose pas de soucis, mais il peut s’avérer que dans la pratique ce ne soit pas pareil.
• Dans la boite de saisie du nom de domaine, assurez vous d’utiliser le nom DNS et non NetBIOS. Pour nous, cela sera formation.local au lieu de FORMATION. Dans le cas où la configuration NetBIOS ai été modifiée sur votre réseau.
• Videz votre cache DNS grâce à la commande ipconfig /flushdns. Faire l’ajout du poste client dans le domaine même si vous savez qu’il va échouer. Vérifiez votre cache DNS grâce à la commande ipconfig /displaydns. Vous devriez avoir une réponse sur _ldap._tcp.dc._msdcs.formation.local vers le FQDN de votre contrôleur de domaine. Si la résolution de nom n’a pas fonctionné, vérifier vos paramètres au niveau du serveur DNS.
• Au niveau des Firewall, le port 445 doit être ouvert entre le client et le DC.
• Microsoft a publié une KB. Personnellement la modification des clés de registre n’a rien changé. Mais certains utilisateurs ont été contant de trouver cette astuce.
• Vérifiez l’activation du service “Assistant TCP/IP NetBIOS“. Cela à réglé le problème chez nous. Et c’est d’ailleurs pour moi un grand mystère. Si quelqu’un a une explication a proposer, je suis preneur.

Raccourcis

Voici une petite liste de raccourcis pour aller plus vite et vous la péter devant vos copains les administrateurs :p

• sysdm.cpl Propriétés Systèmes et ajouter le poste au domaine (serveur / client)
• ncpa.cpl Panneau d’administration des cartes réseaux (serveur / client)
• dsa.msc Gestion des utilisateurs d’Active Directory (serveur)
• services.msc Gestion des services de la machine (serveur / client)
• compmgmt.msc Gestion locale de l’ordinateur (serveur / client)
• ipconfig /displaydns Affiche le cache DNS (Il contient aussi le contenu du fichier C:/Windows/System32/Drivers/etc/host)
• ipconfig /flushdns Vide le cache DNS
• nbtstat -c Affiche le cache NetBIOS
• nbtstat -R Vide le cache NetBIOS

PS : Cette article a été re-publié suite à un crash de la base de donnée.