Loco Team Ubuntu-dz


La Communauté Algérienne des utilisateurs d'Ubuntu

Ubuntu est un projet communautaire de création d’un système d’exploitation et d’un ensemble complet de programmes informatiques utilisant des logiciels libres et gratuits. Au coeur de la Philosophie d’Ubuntu sur la Liberté Logicielle se trouvent ces idéaux philosophiques :

  • Tout utilisateur d’ordinateur devrait avoir la liberté d’exécuter, de copier, de distribuer, d’étudier, de partager, de modifier et d’améliorer ses logiciels pour toutes fins, sans payer aucun frais de licence.
  • Tout utilisateur d’ordinateur devrait pouvoir utiliser ses logiciels dans la langue de son choix.
  • Tout utilisateur d’ordinateur devrait être en mesure d’utiliser tous ses logiciels, même s’il souffre d’un handicap.

    source : http://www.ubuntu-fr.org/ubuntu/philosophie

Depuis ,le 31/12/2010 un message de la communauté Ubuntu algerienne s’est manifesté pour reprendre en main et réactivé la communauté ,02 rendez vous se sont déroulé (sur le canal IRC :Ubuntu-dz) ,le dernier en cours est celui d’hier le 07 janvier.

un résumé de la situation :

Le 31/12/2010 à 22:00 GMT+1 s’est tenue une réunion sur le salon IRC de la team #ubuntu-dz, serveur freenode 

Le thème : Réactivation d’#ubuntu-dz

La réunion a été présidée par Abdelhak (Abdelhack FAREH).

Les points devant être soulevés lors de la réunion  :
- La reconstitution du comité de gestion.
– Les objectifs à réaliser pour 2011.
– Un plan d’activités.
Après débat, il a été décidé de :

  • Décision de reprendre #ubuntu-dz dès le début.
  • Décision de créer 4 groupes :
  • Relation avec les clubs et les universités.- Événements. – Sites web et Technique. – Rédaction et communication.
  • Chaque groupe aura un coordinateur et un adjoint.
  • Faire une (01) réunion en ligne (sur le canal IRC de la team) par mois. Décision du jour sur la ML.
  • Faire deux (02) réunions physique par année. Décision des jours sur la ML.
  • Candidature à devenir coordinateur ou adjoint d’un groupe soumis au vote sur la ML.
  • Les candidats peuvent se proposer dès maintenant.
  • La date de proposition des candidatures est limité au 15 Janvier.
  • Décisions de prise des fonctions des coordinateurs et adjoints des groupes le 31/01/2011.

la réunion du  07/01/2011 ,malgré les evenements qui ont touché le pays a eu lieu et reste toujours a l’écoute .

pour rejoindre la communauté https://wiki.ubuntu.com/AlgerianTeam#Ressources de ma Communauté.

donnez votre avis …

EtherApe,Iftop,Bmon…


iftop-bmon-etherape

Pour compléter l’idée de Freefoxtv.net concernant les outils de Monitoring du moins pour voir son traffic réseau soit de sa carte ou de son reseau local .

sudo apt-get install bmon

bmon : bandwidth monitor

sudo apt-get install ethearpe

Etherape est un moniteur graphique avancé de connexions et flux TCP/IP en temps réel .

et enfin Iftop

La commande iftop permet d’analyser la consommation de bande passante de sa machine linux. Iftop affiche à la manière de top ou htop les débits réseaux des 

sudo apt-get install iftop

iftop -i ethxx

la commande en plus riche .

iftop -h | -npbBP -i interface -f filter code -N net/mask

Bien sur ce sont la des outils parmi d’autres que grace a mon ami Athmane j’ai decouvert tres utile dans des cas .

Merci a toi freefoxtv.

Une Valeur ajoutée pour Firefox add-on extension WorldIP


worlpdipBien que la valeur ajoutée est une culture presque pour tous les domaines ,je remercie deja KT pour deja pour ces encouragements et ces propositions déja dans ce module du navigateur Firefox qui n’arrete pas de m’etonnez je partage celle ci WorldIP qui vous affiche mon IP adresse ,Location,et Country en bas et en haut Remote Host IPLocation et Country . c’est pas trop de chez vous risquez pas de tombé sur une base de données algerienne.on n’a pas de base donnée.

ah j’ai oublié le Flag "le drapeau "pour le Rappel Geographic sinon on sera nul en géo .

Configuration  du add-on :
worldip2

le site :

wipmania

Saha Shourkoum . le Netbook  Zala Ubuntu 9.10 est chez mon cinquieme  utilisateur de Ubuntu dans le cadre faimiliale et dans le cadre Professionnel .Difficile de trouver les memes  experiences . ils se cachent ou ses users ubuntu .

un Sondage et je vais le confirmez grace a mon hebergeur prochain post les statistiques Reseaux sous ubuntu .

allez y donnez votre voix et on verra .



					

				

Service Level Agrement ou Convention de Service


sla panel

Le Service Level Agreement ou SLA est une expression anglaise qui peut être traduite par « Accord de Niveau de Service » ou par « Engagement de Service », ou encore plus simplement « Convention de Service ».

Le SLA est le contrat ou la partie du contrat spécifiant l’ensemble des niveaux de services à fournir par le prestataire informatique au(x) client(s). Il s’agit d’un engagement formel et contraignant, établi entre un prestataire et son (ses) client(s).

Le SLA est utilisé dans la plupart des contrats d’outsourcing et permet de :

  • identifier et définir les besoins du client ;
  • fournir un cadre général de compréhension des deux parties ;
  • simplifier les problèmes complexes ;
  • encourager les dialogues en cas de conflit ;
  • éliminer les attentes irréalistes ;
  • être utilisé comme un instrument de marketing par les services commerciaux et techniques des ASP;
  • transformer une obligation de moyen en obligation de résultat.

L’ASP (Application Service Provider), traduit en français par « Fournisseur d’Applications Hébergées » (FAH), est une société qui fournit, sur abonnement, un accès à des applications ainsi que de l’infrastructure et la maintenance nécessaires.

Contrairement à l’outsourcing classique, l’ASP ne reprend pas l’infrastructure IT existante du client pour gérer ses ressources informatiques, mais fournit au client un accès à sa propre infrastructure IT.

Dans la mesure où l’ASP doit combiner des compétences dans le service, la technologie des réseaux et leur gestion mais aussi dans l’administration, l’intégration, la gestion et le support des applications, il sera amené à s’octroyer plusieurs partenaires.

Toutefois, sur la base du contrat ainsi que du SLA, l’ASP restera le seul responsable, à l’égard du client, de la livraison du service. Il maintiendra donc de nombreuses relations avec des sociétés telles que des fournisseurs de système d’exploitation, des fournisseurs de hardware, des fournisseurs d’équipement de réseaux, des fournisseurs de réseaux, d’applications, et d’autres fournisseurs d’infrastructure, etc…

Il s’agira notamment des prestataires suivants :

  • ISV (Independent Software Vendor – vendeur indépendant de logiciels),
  • AIP (Application Infrastructure Provider – fournisseur d’infrastructure d’applications),
  • NSP (Network Service Provider – fournisseur de services réseaux),
  • VAR (Value Added Reseller – revendeur à valeur ajoutée),
  • SI (Systems Integrator – intégrateur de systèmes), …

La rédaction du SLA

Le SLA fait partie intégrante du contrat entre l’ASP et son client. Il fait souvent l’objet d’une annexe à ce contrat.

L’office Mondial de la Propriété Intellectuelle (OMPI) et l’ASPIC ont mis au point des Best Practices, afin de prévenir certains litiges fréquents entre l’ASP et son client. Celles-ci portent sur l’identification de l’infrastructure, la connectivité, la sécurité, l’application, l’implémentation et la maintenance des services.

Le SLA en lui-même doit prévoir un maximum de situations pour concentrer les obligations et le niveau de service à fournir.

On y retrouvera le temps imparti dans lequel les services seront fournis, la description et l’étendue des services qui seront fournis, ceux qui ne devront pas être fournis, un calendrier des implémentations, les utilisateurs du service et leur localisation.

Le cœur du SLA réside dans les clauses fixant le niveau des services attendus, à savoir le taux de disponibilité et de fiabilité du service (par exemple : les heures et les jours pendant lesquels le service sera disponible).

Sera également précisé le temps de réponse qui devra être octroyé au fournisseur en cas de plainte pour dysfonctionnement (par exemple, prévoir que 95% des problèmes seront résolus après une heure à compter de la plainte).

Les conditions de payement devront être également très précises ainsi que les procédures qui en découlent. Il faudra de même prévoir les modalités des licences de logiciels, les titulaires des droits y attenant, et leurs conditions financières, la propriété des données, leur protection, leur confidentialité ainsi que leur récupération (dans quelles circonstances, suivant quelle procédure et conditions).

Un autre point crucial concerne la détermination des obligations du client, comme l’ « updating » de son infrastructure pour assurer la compatibilité avec les services de l’ASP, la formation de son personnel, la fourniture d’informations correctes à ses utilisateurs…

S’ensuit la phase de « reporting ». Le SLA doit examiner concrètement comment les services seront contrôlés, avec quels outils, suivant quelle procédure d’audit, par qui, à quelle fréquence etc., pour pouvoir éventuellement engager ensuite la procédure de plainte qui sera très précisément décrite (la personne à contacter, la manière de formuler les plaintes, les procédures d’urgence, les temps maximum dans lesquels l’ASP devra réagir etc.). Des outils de support à toute ces procédures doivent également être pointés, leur niveau et nature (helpdesk, combien d’opérateurs y sont disponibles, de quelle heure à quelle heure, quel jour, qui sont les personnes payées pour répondre à toute question, qui est responsable pour le « service clientèle » au sein de l’ASP, …).

Par ailleurs, il sera fait expressément mention des crédits de service, compensations financières, pénalités ou autres conséquences de la fourniture défectueuse des services.

Les clauses de sécurité revêtent également une importance capitale au sein d’un SLA. Comment prévoir que la sécurité d’accès au système est valablement assurée ? Il sera donc nécessaire de prévoir une procédure de recouvrement de données et des copies de sauvegarde.

L’étendue de la responsabilité, de l’indemnisation de l’ASP vis-à-vis des tiers, et des autres intervenants dans le projet (ISV, VAR, …) doit être définie. En particulier, seront visées les limitations de sa responsabilité et la prévision des cas de force majeure applicables.

Enfin, des modes de résiliation précis devront être stipulés, ainsi que d’éventuels modes de résolution des litiges (tels que prévus par les recommandations de l’ASPIC par exemple).

Pourquoi un SLA peut-il échouer ?

La cause principale de litiges réside dans le processus de négociation. En effet, dans son appel d’offres, le client définira ses besoins et ses objectifs. Le fournisseur de services IT, quant à lui, devra délimiter son périmètre de services, et de maintenance éventuelle, qu’il pourra fournir au client. Ce processus de rapprochement n’est pas aisé, et devra parfois nécessiter l’intervention de tiers.

Le Service Level Management, n’est pas toujours bien mis en place. Vu la complexité du secteur de l’IT et du marché de l’ASP, un contrôle est très difficile mais s’avère, pour la même raison, essentiel. Le client se doit donc de mettre en place un système spécialement conçu (logiciel par exemple) pour effectuer le suivi des niveaux de service se trouvant dans le SLA , ainsi que le contrôle des procédures de rapport, de modifications des services ou de la gestion des conflits.

Les spécifications sont souvent lacunaires : soit qu’elles ne sont pas claires, soit qu’elles sont incomplètes.

Le manque de clarté se retrouve en effet souvent dans la délimitation du paramètre « disponibilité ». La disponibilité d’un réseau, par exemple, est souvent spécifiée par une figure de pourcentage de disponibilité. Cependant, on oublie souvent de spécifier l’effectivité d’un service au sein du plan commercial du client. Si on stipule une disponibilité de 98%, comment la mesurer, à quoi correspondent-elle et quels sont les 2% restants ?

Quant aux services en tant que tels, leur description est souvent incomplète. Par exemple, des clauses à propos de la sécurité et des dégâts qui peuvent être causés doivent être définis de manière exhaustive. Trop souvent, ces derniers ne sont pas bien classifiés ou quantifiés, ce qui entraîne des confusions et incompréhensions à propos des responsabilités de chacun, et donc parfois … de longues procédures judiciaires.

Par ailleurs, la plupart des SLA se concentrent trop sur les efforts et moyens déployés par un prestataire de service dans le cadre de tel ou tel problème, en oubliant qu’il y a un résultat à atteindre. Au lieu de prévoir « le service X fournira à votre société le résultat Y », l’on prévoit «  dans le cas où le système se bloque, le prestataire X apportera son service à concurrence du temps Y ».

Le prix est souvent mal défini. Si l’on rentre dans une logique de forfait, il est alors très difficile pour le client de déterminer un rapport prix/exécution.

Enfin, au vu de tous les éléments précités, le SLA sera souvent considéré et rédigé comme un document hautement technique, dont la compréhension est réservée à des initiés…

Les défis du SLA sont donc de dépasser ce cadre technique de la fourniture d’un service pour parvenir à une compréhension des besoins de chacun.

Thibault Verbiest
Avocat aux barreaux de Paris et de Bruxelles (Ulys).

En Algérie , ce systéme est offert dans nos plateforme que ca soit l’Opérateur National ou les Opérateurs privés . Alors Messieurs les administrateurs avant de chercher le coupable chercher les Problémes ,Certains Equipements parlent .

Ou tout simplement faites des Rapports d’analyse .

Suivre

Recevez les nouvelles publications par mail.

Rejoignez 45 autres abonnés