Comment effacer la file d'attente d'imprimante ?

Posted by IT NISRO 0 commentaires

 Avez-vous déjà été dans une situation où vous essayez d'imprimer quelque chose et rien ne se passe? Vous attendez qu'il soit imprimé, mais le travail ne passe pas? Il ya une tonne de raisons pour lesquelles un travail d'impression ne peut pas être réellement imprimé, mais l'une des causes courantes est que la file d'attente de l'imprimante a un travail d'impression bloqué.

Cela peut se produire pour un certain nombre de raisons. Disons que vous avez essayé d'imprimer quelque chose quelques heures en arrière, mais l'imprimante était éteinte. Vous avez fini par ne pas avoir besoin du document et vous l’avez oublié. Puis vous revenez et vous essayez d'imprimer à nouveauLe travail d'impression est ajouté à la file d'attente et si le travail précédent n'a pas été supprimé automatiquement, le nouveau sera derrière ce travail d'impression qui ne s'est jamais imprimé.

Parfois, vous pouvez entrer manuellement et supprimer le travail d'impression, mais parfois vous ne pouvez pas vous débarrasser de lui. Dans ce type de cas, vous devez effacer la file d'attente d'impression manuellement. Dans cet article, vous verrez les étapes pour effacer la file d'attente d'impression.

 

Effacer la file d'attente d'imprimante dans Windows  

Pour que les services d'impression soient remontés et en cours d'exécution, procédez comme suit:

  1.  Allez dans Démarrer, panneau de contrôle et outils d'administration. Double-cliquez sur l'icône Services.
     
  2.  Faites défiler vers le bas jusqu'au service spouleur d'impression et cliquez avec le bouton droit et sélectionnez arrêter. Pour ce faire, vous devez être connecté en tant qu'administrateur. À ce stade, personne ne sera en mesure d'imprimer quoi que ce soit sur l'une des imprimantes qui sont hébergées sur ce serveur. 


     
  3. Ensuite, vous devez aller dans le répertoire suivant: C:\WINDOWS\System32\spool\PRINTERS.

Cela effacera toutes les files d'attente d'impression (si vous faites cela sur un serveur, c'est une bonne idée d'abord de vous assurer qu'il n'y a pas d'autres travaux d'impression en cours de traitement pour l'un des autres imprimantes sur le serveur parce que faire cette étape va supprimer ces travaux également).

  •  Maintenant, vous pouvez revenir à la console de services, cliquez avec le bouton droit et choisissez Démarrer pour le service spouleur d'impression.

À ce stade, vous devriez être en mesure d'imprimer sans problème. Si vous préférez utiliser un script, c'est-à-dire pour un serveur, vous pouvez créer un fichier batch avec les commandes ci-dessous ou simplement les taper dans l'invite de commande:

  • net stop Spooler
  • del %systemroot%\System32\spool\printers\* /Q /F /S
  • net start spooler

Les premières et troisièmes commandes sont assez évidentes: elles s'arrêtent et démarrent le service spouleur d'impression.

 

Conclusion                                                                      

Lorsque vous imprimez un document ou une image, Windows place le document ou l’image dans une file d'attente et il est appelé file d'attente d'impression. En bref, la file d'attente d'impression n'est rien d'autre qu'une liste de documents en attente d'impression.

Windows 10 efface automatiquement la file d'attente d'impression lorsque l'imprimante termine tous les travaux en attente.

Mais parfois, vous devrez peut-être effacer manuellement la file d'attente d'impression pour résoudre un travail d'impression bloqué.

DNSSEC ( Domain Name System Security Extensions )

Posted by IT NISRO 0 commentaires

 DNS est l'un des premiers protocoles à avoir vu le jour. Il a été défini et implémenté dans les années 80, c'est une brique fondamentale dans l'internet d'aujourd'hui.

On peut le comparer à une base de donnée distribuée sur des milllions de machines. Il permet de faire la relation entre le nom d'une machine sur le web et son adresse IP.

Il est composé de 13 serveurs racines répartis dans le monde, qui constituent le point d'entrée dans le schéma arborescant (hiérarchique) ci-dessous. Ensuite viennent les « Top-Level Domains » ou domaines de premier niveau (.fr, .com, etc..) puis les noms de domaine classiques comme « fnac.fr ». DNS repose sur un système de communication entre ces différentes strates pour pouvoir identifier la machine étant capable de donner la réponse a la requête d'un internaute.

Racine DNS

Arborescance hiérarchique DNS


Lorsqu'un utilisateur souhaite accéder à un site web, il utilise généralement un nom. Ce nom est très pratique car il est beaucoup plus simple à retenir qu'une adresse IP mais il nécessite d'être résolu. Et pour ce faire, DNS utilise un processus particulier. Avant tout l'utilisateur va faire suivre sa requête de résolution à un résolveur distant, qui est souvent par défaut le résolveur du FAI concerné. Par exemple pour www.wikipedia.fr, le résolveur va alors entamer la procédure suivante :

  • Demande l'adresse du TLD « .fr » à l'un des serveurs racine
  • Demande l'adresse du serveur « wikipedia.fr » au serveur .fr
  • Demande l'enregistrement « www » au serveur wikipedia.fr
  • Le résolveur envoie finalement la réponse à l'utilisateur qui peut désormais interroger son serveur web
Resolution DNS classique

La résolution DNS (www.afnic.fr)


Par défaut DNS utilise UDP et ne chiffre pas ses paquets. Dans la capture suivante nous pouvons voir tous les champs qui composent un paquet. Nous noterons que certains sont plus sensibles que d'autres :

  • Identification : Un identifiant de 16 bits généré aléatoirement. Cet identifiant est copié dans la réponse correspondante à la requête initiale. Il est nécessaire qu'un nouveau nombre aléatoire, de 16 bits, soit généré pour chaque demande.
  • Total Additional Resource Records : Permet de rajouter des enregistrement supplémantaires dans la réponse à une requête.
DNS Header

Vulnérabilités                                                                                           

DNS n’est pas sur (RFC 3833), les principaux problèmes connus sont :

  • Le Cache Poisonning
  • Les attaques de type Denial of Service
  • Le Name Chaining
  • L'interception de paquets
  • Le brute force du champ Identification

La RFC 3833 décrit plutôt bien ces problèmes, nous nous intéresserons surtout à l'un d'eux qui est à l'origine de plusieurs attaques, le Cache Poisonning :

On peut citer l'attaque de Bradesco au travers du FAI Brésilien NET Virtua que l'on soupçonne d'avoir été empoisonné. La faille Kaminsky révélée à la Black Hat 2008 dénonce se problème et démontre comment empoisonner un serveur de noms pour qu'il réponde de fausses informations.

Explication :
Dans le cas d'un serveur A, envoyant une requête vers un serveur B. L'objectif du "Pirate" est de faire passer l'une de ses propres réponses pour une réponse du serveur B, et ainsi empoisoner le cache du serveur A. Dans se cas le serveur A, répondra la fausse information transmise par le pirate lorsqu'on lui posera la bonne question.
Dans un premier temps, le pirate déclanche la résolution d'une adresse par le serveur A en lui envoyant des requêtes. Ensuite, sachant que le serveur A va envoyer des requêtes et attendre des résponses, le pirate va pouvoir forger des réponses erronées et les envoyer au serveur A.
Cette attaque est possible principalement du au fait qu'il n'y ai pas d'authentification. La seule authentification se base sur le fait que la réponse doit avoir la même valeur que la requête dans le champ Identification du paquet DNS et que le port soit le bon.

DNS cache poisonning

Problématique et enjeux                                                                          

Tout ceci fait émerger la problématique suivante :

Comment assurer l’intégrité des données et authentifier les résolveurs / serveurs faisant autorité tout en conservant la rétrocompatibilité avec DNS ?

Les principaux enjeux sont sont de pouvoir :

  • Assurer la sécurité d’accès à la ressource demandée aux 3 milliards d’utilisateurs
  • Trouver une solution assez légère pour ne pas surcharger les serveurs de noms.

Domain Name System Security Extensions

Introduction                                                                                         

Qu'est-ce que DNSSEC ?

  • Sécurisation des données (pas du canal) à travers un mécanisme de clés asymétriques
  • Signe les enregistrements DNS de sa propre zone
  • Chaque zone DNS parente, garantie l’authenticité des clés de ses zones filles en les signant
  • Permet d’établir une « chaine de confiance » jusqu’à la racine DNS

Qu'est-ce que n'est pas DNSSEC ?

  • Pas de chiffrement des enregistrements DNS
  • Pas de confidentialité des échanges
  • Ne garantit pas la sécurité d’un transaction (au sens certificat SSL)

Fonctionnement                                                                                  

DNSSEC repose avant tout sur un système de confiance des enregistrements DNS par signature.

Chaque information DNS est signée avec une clé privée et transmise avec l'information en elle même, de sorte à ce que les serveurs de résolution (ayant la clé publique) soient en mesure de déterminer la véracité de l'information.

Système de clés DNSSEC

Signature et authentification de clés DNSSEC (www.afnic.fr)


Au fur et a mesure que le système de signature d'enregistrements s'étend à l'arborescance DNS, une chaine de confiance s'installe. En effet, DNSSEC ne se base pas seulement sur la signature des enregistrements DNS. Il permet également de signer les clés publiques de manière hiérarchique. Ainsi, la zone mère signe toujours les clés publiques de ses zones filles, il en va ainsi jusqu'au domaine recherché.

De ce fait, lorsque le résolveur de notre FAI doit résoudre un nom, il n'a besoin que de la clé privée de la racine, ce qui lui permet de faire confiance à toutes les clés ascendantes.

Chaine de confiance DNSSEC

La chaine de confiance DNSSEC (www.afnic.fr)


Le déploiement                                                                                       

DNSSEC a été adopté et est aujourd'hui en déploiement depuis presque 5 ans, les RR de la zone racine ont étés signés en Juillet 2010, ceux du .fr en Septembre 2010.

En France l'Afnic (Association française pour le nommage Internet en coopération) s'engage dans la promotion de DNSSEC :

  • Elle propose notamment à ses bureaux d’enregistrement accrédités une remise de 20% sur le tarif des créations et la maintenances de noms de domaine en .fr signés par DNSSEC

De ce fait, plusieurs « registrars » proposent le déploiement DNSSEC à leurs clients (nous !) :

DNS cache poisonning

Avoir son propre résolveur DNSSEC ?                                                

Une question subsiste cependant, pourquoi pas avoir son propre résolveur DNSSEC ? Après tout même si le résolveur de notre FAI de la résolution DNS, cela ne garanti pas la protection entre ce dernier et notre machine.

Pourquoi avoir son résolveur :

  • Assurer son adhérence à la « chaine de confiance »
  • Contourner la censure réalisée par certains résolveurs (DNS RPZ)
  • On ne fait plus confiance aux DNS potentiellement fournis par DHCP (hotspots..)

A quel niveau, local ? distant ?

  • Au niveau local, la « chaine de confiance » est complète car la validation DNSSEC est locale mais on perd la notion de cache partagé => accroit la charge sur la racine
  • Au niveau distant, on a la possibilité de mutualiser le service et aussi de faire du partage de cache

Au final je pense que oui, il peut être intéressant d'avoir son propore résolveur. Mais que cela dépend vraiment des usages et du niveau de paranoïa de l'intéressé.

Installer son propre résolveur local

Exemple avec Unbound qui est un serveur DNS permettant de faire du DNSSEC (BIND le fait aussi)

  • Dans /var/unbound/etc/unbound.conf :
    server:
    interface: 127.0.0.1
    auto-trust-anchor-file: "/var/lib/unbound/root.key"
  • Récupération de la clé de la racine :
    unbound-anchor -a "/var/lib/unbound/root.key"
  • Dans /etc/resolvconf/resolv.conf.d/head :
    nameserver 127.0.0.1

Les alternatives                                                                                      

Il existe des alternatives, qui n'utilisent pas le même système de sécurisation :

DNSCurve : Sécurisation du canal (contrairement a DNSSEC)

  • Inutile si le serveur distant est un serveur pirate

DNSCrypt : Chiffre aussi le trafic DNS (simple)

  • Outil open source
  • Développé par OpenDNS

Conclusion                                                                                              

Ce qu'il faut retenir de DNSSEC :

  • DNSSEC protège contre des failles de type Kaminsky (cache poisoning)
  • Il est en bonne voie de déploiement
  • Il n’est pas simple à maintenir (rollover de clés asymétriques)
  • Repose sur la compétence des différents acteurs de la chaine de confiance.


Symfony

Posted by IT NISRO 0 commentaires

 Symfony est un Framework PHP, crée par la société SensioLabs en 2005.

Il a été inventé par des français et est totalement open source et gratuit.
Il utilise une architecture MVC ce qui permet un meilleur travail d'équipe et une meilleur distribution du travail. De plus il fonctionne avec un ORM.
Il est utilisé par de nombreuses sociétés et par nombreux outils tel que : Drupal, PhpBB ou encore Laravel.

Pourquoi choisir un Framework ?

Un Framework permet :

  • Un gain de productivité : il implétente beaucoup de fonctionalitées basiques et rend les opérations native plus simple.
  • Un code bien structuré : il utilise de nombreux patterns et des architectures très connues telles que MVC
  • De disposer de nombreux outils : il permet de gérer des formulaires, des utilisateurs… de façon simple
  • D'améliorer la façon de travailler : il permet le travail d’équipe, le découpage et la séparation entre les développeurs PHP et le designer. Permet la reprise de code par d’autres developpeurs.
  • D'obtenir de l'aide et des mises à jours : Cours, tutoriaux, aide sur les forums, mis à jour régulièrement avec souvent un support à long terme.

Structure

L'architecture MVC

L'architecture MVC de Symfony peu être représentée de cette façon :

Lorsqu'un client demande une URL, celle-ci est d'abord traitée par le controleur fontrale de Symfony avant d'être envoyée au noyaux.
Quand le noyaux reçois la demande d'une URL, il appel le service de routing, celui-ci va alors lui indiquer le contrôleur à appeler pour l'URL que le client demande.
Le noyaux appel alors le contrôleur qui va si il en a besoin, appeler le modèle et générer la vue.
Quand le contrôleur a fini que générer la vue, il retourne le résultat au noyaux, celui-ci va alors transmettre la réponse au client.

Les ORM

ORM signifie Object Relational Mapping. Il permet de créer l'illusion d'une base de données orientée objet à partir d'une base de données relationnelle, en transformant l'ensemble des relations en objet.
Il existe deux types d'ORM :

  • Data Mapped (Doctrine) : Permet une abstraction plus puissante avec la base de données, on envoie l’objet à un manager pour le sauvegarder en base de données.
  • Active Record (Propel) : Un objet est une ligne de la base de données, chaque champs est une colonne, la méthode save() est présente sur chaque objet.
Data mappedActive record
$user = new User;
$user->setName('Antoine');
EntityManager::persist($user);
$user = new User;
$user->setName('Antoine');
$user->save();

Doctrine permet d'avoir une abstraction plus forte avec la base de données afin d'éviter les problèmes de couplage fort. Cependant cette abstraction a un prix sur ses performances, en effet le manager d'entité est lourd comparé au patterns active record qui contient le code de persistance directement de la classe concernée. Le pattern active record est très intéressant dans le cas d'une structure CRUD.

Voici un exemple de requêtes Doctrine :

$this->getUserRepository()
           ->createQueryBuilder('u')
           ->select('u, p')
           ->leftJoin('u.profile', 'p')
           ->where('u.login = :login')
           ->setParameter('login', 'b.rossi')
           ->getQuery();

Doctrine génère alors le code SQL suivant :

SELECT * FROM  user u LEFT JOIN lnk_user_profile lup ON u.id = lup.user_id LEFT JOIN profile p ON lup.profile_id = p.id WHERE u.login = 'b.rossi';

L'arborescence

L'arborescence d'un projet Symfony est la suivante :

			.
			├── app
			│   ├── config (Contient la configuration générale de l’application Symfony : Connexion à la base de donnée, Routing général, Configuration de la sécurité et du firewall, Configuration générale (mail, ORM…))
			│   └── Resources (Contient les ressources générales de l’application Symfony : Les fichiers de traduction, La vue de base)
			├── bin (Contient l’executable Symfony et Doctrine)
			├── src (Contient les bundles de chaque projet)
			│   └── Dms
			│       ├── ClaimBundle
			│       ├── CoreBundle
			│       └── PlanningBundle
			├── var (Contient les fichiers de cache et les fichiers de log)
			│   ├── cache
			│   └── logs
			├── vendor (Contient les librairies utilisées dans Symfony)
			│   ├── composer
			│   ├── doctrine
			│   ├── swiftmailer
			│   ├── symfony
			│   └── twig
			└── web (Contient les fichiers js / css / images pour chaque bundle (une fois généré))
			    └── bundles
         ├── dmsclaim          ├── dmscore    └── dmsplanning

Fonctionnement

Les bundles

Un bundle est un répertoire qui a une structure bien définie et qui peut héberger à peu près tout : des classes aux contrôleurs en passant par les ressources web (C'est une version amélirée des plugins).
Un bunble à la structure suivante :

			.
			├── Controller (Contient les contrôleurs du bundle)
			│   └── IndexController.php
			├── DependencyInjection (Contient les injections de dépendance)
			├── EventListener (Contient les listener qui vont se déclencher lors de certains évènements (ex: lors d’une requête))
			├── Resources (Contient les configurations du bundle (routes, services…))
			│   ├── config
			│   │   └── routing.yml
			│   │   └── services.yml
			│   ├── public (Contient les fichiers css / js / images)
			│   ├── translations (Contient les traductions du bundle)
			│   └── views (Contient les vues du bundle qui sont appelées par les contrôleurs)
			│       └── index.html.twig
			├── Services (Contient les services)
			└── Tests (Contient les tests)
			

Le routing et les configurations (yml, xml, php)

Le routing permet d’associer une URL à un contrôleur et à une action de celui-ci.
Il existe 4 formats d’écriture des fichiers de route:

  • Les annotations
  • Le Yaml
  • Le XML
  • Le PHP

Et 3 formats pour les fichiers de configuration:

  • Le Yaml
  • Le XML
  • Le PHP

Voici un exemple de route écrit en Annotation :

			// src/AppBundle/Controller/BlogController.php
			class BlogController extends Controller {

				/** * @Route("/blog/{culture}") */
				public function showAction($culture) {
				// …
				}

			}
		

Voici un exemple de route écrit en Yaml :

			# src/AppBundle/Resources/config/routing.yml
			blog_show:
			   path: /blog/{culture}
			   defaults: { _controller: AppBundle:Blog:show }
   				requirements:
   					culture: en|fr
		

Voici un exemple de route écrit en XML :

			<!-- src/AppBundle/Resources/config/routing.xml -->
			<?xml version="1.0" encoding="UTF-8" ?>
			<routes xmlns="http://symfony.com/schema/routing" 
					xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
					xsi:schemaLocation="http://symfony.com/schema/routing http://symfony.com/schema/routing/routing-1.0.xsd">
			   <route id="blog_show" path="/blog/{culture}">
					<default key="_controller">AppBundle:Blog:show</default>
			   </route>
			</routes>
		

Voici un exemple de route écrit en PHP :

			// src/AppBundle/Resources/config/routing.php
			use Symfony\Component\Routing\RouteCollection;
			use Symfony\Component\Routing\Route;
			$collection = new RouteCollection();
			$collection->add('blog_show', new Route('/blog/{culture}', array('_controller' => 'AppBundle:Blog:show')));
			return $collection;
		

Les annotations et le format Yaml sont les deux formats les plus utilisés dans Symfony de par leur syntaxe simple et lisible.

Les contrôleurs

Voici un exemple de contrôleur Symfony :

			<?php
			namespace MyProject\BlogBundle\Controller;
			use MyProject\CoreBundle\Controller\Common\BaseController;
			use Doctrine\ORM\Query;
			use Symfony\Component\HttpFoundation\Request;
			class BlogController extends BaseController {
		
		    	/** * @Route("/article/{id}") */
    			public function articleAction(Request $request, $id) {
         			$culture = $request->getLocale();
			        // Requête pour récupérer l'article (on appel le modèle)
          			$article = $this->getDoctrine()->getManager()->getRepository("MyProjectBlogBundle:Article")->find($id);

          			// On appel la vue
			        return $this->render('MyProjectBlogBundle:article.html.twig', array('culture' => $culture, 'article' => $article));
    			}

			}
			?>
		

Dans cet exemple de contôleur appel le modèle pour récupérer un article puis génère la vue en lui donnant les informations qu'elle a besoin.

Les vues (Twig / PHP)

Voici un exemple de vue Twig :

			<!DOCTYPE html>
			<html>
			    <head> 
			       <title>
			           {% block title %}
			                   Blog :: 
			           {% endblock %}
			       </title>
			       {% block stylesheets %}
			           <link rel="stylesheet" href="{{ asset('bundles/myprojectblog/css/jquery.css') }}" type="text/css" />
			       {% endblock %}
			      
			       {% block javascripts %}
			           <script language="javascript" src="{{ asset('bundles/myprojectblog/js/jquery.js') }}"></script>
			       {% endblock %}
			    </head>
			    <body>
			            {% block content %}{% endblock %}
			                  {# END - BLOCK RESERVE AUX PLUGINS JQUERY UI UTILISANT LE CSS #}
			            {% block endJavascripts %}{% endblock %}
			    </body>
			</html>
		

Twig est un language simple qui permet l'héritage et l'imbracation. Sont language étant limité, cela permet d'éviter aux développeurs peu expérimentés d'écrire du code dans la partie template.
Dans l'exemple suivant, le code Twig redéfini ou surcharge les valeurs contenu dans les blocks du templates hérité (parent).

			{% extends 'MyProjectBlogBundle::layout.html.twig' %}
			{% block title %}
			    {{ parent() }} Article
			{% endblock %}
			{% block content %}
			    <h2>{{ article.title|trans }}</h>
			    <div class="content">
			       {% include('MyProjectBlogBundle:Article:content.html.twig') %}
			       {% autoescape false %}
			           {{ text }}
			       {% endautoescape %}
			    </div>
			{% endblock %}
		

Les modèles (yml, annotation, xml)

La partie modèle permet de définir la structure et les relations des objets par rapport à la base de données relationelle.
Elle peut être écrite sous forme d'annotation directement dans les classes des objets, en xml ou en Yaml.
Voici un exemple en Yaml :

			MyProject\CoreBundle\Entity\User:
		    type: entity
		    repositoryClass: MyProject\CoreBundle\Repository\UserRepository
		    table: user
		         id:
		           id:
		               type: integer
		               nullable: false
		               unsigned: false
		               id: true
		               generator:
		               		strategy: IDENTITY
		    fields:
		           login:
		               type: string
		               nullable: false
		               length: 255
		    manyToMany:
		           profile:
		               targetEntity: Profile
		               inversedBy: user
		               joinTable:
		                       name: lnk_user_profile
		                       joinColumns:
		                       		name: user_id
		                       			referencedColumnName: id
		                       inverseJoinColumns:
		                       		name: profile_id
		                       			referencedColumnName: id
		

Les formulaires

Les formulaires peuvent être crée de deux façon :

  • Avec une classe

    $mail = new Mail();
    $form = $this->createForm(new MailType(), $mail);
  • Avec un builder

    $form = $this->createFormBuilder()
               ->setAction($this->generateUrl('change_email_password'))
               ->add('email', 'repeated', array('type' => 'email'))
               ->getForm();

Les classes servent quand le formulaire est réutilisé plusieurs fois, ou lorsqu'il est lié à une entité.
Le builder est utile uniquement lorsque le formulaire est utilisé une seule fois, cela évite d'écrite trop de code.
Ce code doit être écrit dans le contrôleur et l'objet suivant doit être donnée à la vue pour qu'elle génère le formulaire :

$form->createView();

Pour afficher le formulaire voici un exemple de code à écrire dans la vue :

			{{ form_start(form, {'action': path('new_mail', {'id': 10})}) }}
			{{ form_errors(form) }}
			<div id="email">
			{{ form_label(form.email) }}
			      {{ form_widget(form.email) }}
			      {{ form_errors(form.email) }}
			</div>
			<div id="subject">
			{{ form_label(form.subject) }}
			      {{ form_widget(form.subject, {'attr': {'class': 'subject', 'title': 'Votre subjet'}) }}
			      {{ form_errors(form.subject) }}
			</div>
			<nput type="submit" />
			{{ form_end(form) }}
		

Les formulaires Symfony permettent :

  • La génération des champs manquants
  • La génération du token pour éviter les attaques CSRF
  • La génération des validateurs HTML5
  • La gestion des messages d’erreur

Afin de vérifier la valider d'un formulaire, Symfony met à disposition un sytème de validation :

			$mail = new Mail();
			$form = $this->createForm(new MailType(), $mail);
			      
			$form->handleRequest($request);
			if ($form->isValid()) {
			    // sauvegarde des éléments de votre formulaire qui ne sont pas mappés avec l'objet
			    ...
			    // sauvegarde de votre objet qui a été mis à jour par le formulaire
			    $em = $this->getDoctrine()->getManager();    $em->persist($mail);    $em->flush();

			        // redirige vers une autre page
			}

			// retourne sur la page du formulaire et affiche des messages d’erreur
		

Communauté et documentation

Communauté et documentation

Symfony dispose d'une très grosse communauté et d'une très bonne documentation.

Il existe des groupes de discussion sur google, un channel IRC, des formations payantes par les réalisateurs du Framework, des sites communautaire très actifs (stackoverflow, openclassroom…), des sites recensants les différents plugins et des outils intégrés dans les IDE tels que Netbeans.

La documentation en ligne est découpée en plusieurs parties :

  • Book : Qui permet d'appendre l'ensemble du fonctionnement de Symfony (les bases et sa structure).
  • Cookbook : Qui permet de trouver les solutions aux problèmes les plus courant (ex: envoyer un mail via google).
  • The component : Qui permet d'approfondir les connaissances sur chacun des composants de Symfony.
  • Best Practices : Qui permet d'apprendre à utiliser Somfony de la meilleur façon.

Conclusion

Conclusion

Symfony permet de faire de nombreuses choses facilement, il nécéssite cependant un temps d’apprentissage est non négligeable.
Malgré cela il est un outil de travail performant qui accroitera la productivé.
Sa grande communauté et sa documentation complete permettent une prise en main guidée et une aide en cas de problèmes.
Cepedant il reste relativement lourd (et gourmand en ressources) lors de l’exécution, il faut mettre en place APC et désactiver Xdebug afin d’avoir de bonnes performances.
Pour des petits projets il faut envisager d’utiliser des Framework tels que Laravel qui sont plus légers et beaucoup plus simples à prendre en main.


Installation Fedora 33

Posted by IT NISRO 0 commentaires

 Téléchargez Fedora 33 (publié le 27 octobre 2020) à partir du site suivant.

    http://download.fedoraproject.org/pub/fedora/linux/releases/33/Server/x86_64/iso/


Installation Fedora 33                                                                                              

[1] Insérez le disque d'installation de Fedora 33 et démarrez l'ordinateur. Ensuite, le programme d'installation de Fedora 33 démarre comme suit. Appuyez sur la touche Entrée pour passer à l'étape suivante.




[2] Sélectionnez la langue que vous souhaitez utiliser lors de l'installation. La langue sélectionnée ici sera également définie comme langue par défaut du système. Si vous ne modifiez jamais le paramètre [Prise en charge de la langue] à l'étape suivante.




[3] Il s'agit de la section Résumé de l'installation par défaut pour certaines configurations de base. Dans cet exemple, configurez la carte du clavier dans la catégorie [LOCALISATION], cliquez sur l'icône [Clavier].




[4] Cliquez sur le bouton [+] en bas à gauche.




[5] Sélectionnez votre type de clavier dans la liste et cliquez sur le bouton [Ajouter].



[6] Après avoir ajouté la disposition du clavier, envoyez votre clavier en haut pour la 1ère priorité comme suit et cliquez sur le bouton [Terminé] en haut à gauche pour terminer.


[7] Retournez à la section Résumé de l'installation par défaut comme [3], Ensuite, définissez votre fuseau horaire, cliquez sur l'icône [Heure et date].
Cliquez sur un point de la carte pour lequel vous souhaitez définir votre fuseau horaire et appuyez sur le bouton [Terminé] qui se trouve en haut à gauche.



[8] Revenez à la section Résumé de l'installation par défaut comme [3], Ensuite, cliquez sur l'icône [Sélection de logiciel] pour installer Fedora.
Choisissez la sélection de logiciels dans la liste que vous souhaitez installer. Dans cet exemple, il choisit la sélection [Fedora Server Edition].



[9] Retournez à la section Résumé de l'installation par défaut comme [3], Ensuite, cliquez sur l'icône [Destination d'installation] pour sélectionner un disque sur lequel vous installez Fedora.
Si certains disques durs sont connectés à votre ordinateur, vous devez sélectionner un disque de destination d'installation.
De plus, si vous souhaitez modifier les dispositions de partition manuellement, sélectionnez [Personnalisé] dans la section [Configuration de stockage],
mais si vous sélectionnez [Automatique] sur celle-ci, le partitionnement est automatiquement effectué. Ensuite, le partitionnement est configuré comme [/ boot], [/], [/ home], [swap].
(mais si la taille du disque de destination est petite comme suit, / home n'est pas séparé).
Si tout est OK, cliquez sur le bouton [Terminé] en haut à gauche pour terminer la configuration du disque.




[10] Revenez à la section Résumé de l'installation par défaut comme [3], Ensuite, cliquez sur l'icône [Network & Host Name].
Si vous avez déjà un nom d'hôte pour ce nouveau serveur Fedora, saisissez le nom d'hôte dans le champ [Nom d'hôte].


[11] Retournez à la section Résumé de l'installation par défaut comme [3], Ensuite, cliquez sur l'icône [Mot de passe racine] sous la catégorie [PARAMÈTRES UTILISATEUR].
Définissez ici le mot de passe du compte root si vous activez le compte d'utilisateur root.



[12] Revenez à la section Résumé de l'installation par défaut comme [3], Ensuite, cliquez sur l'icône [Création utilisateur] sous la catégorie [PARAMÈTRES UTILISATEUR].
Créez un compte utilisateur commun ici. Si vous désactivez le compte d'utilisateur root dans la section précédente, cochez une case [Rendre cet utilisateur administrateur] pour accorder des privilèges administratifs à ce compte commun.


[13] Confirmez les sélections et si tout est OK, cliquez sur [Commencer l'installation] pour installer Fedora.




[14] Une fois l'installation terminée, cliquez sur le bouton [Redémarrer le système] en bas à droite pour redémarrer l'ordinateur.




[15] Après le redémarrage de l'ordinateur, l'invite de connexion s'affiche comme suit. Connectez-vous avec l'utilisateur root ou un utilisateur commun que vous avez défini lors de l'installation. Si vous êtes connecté normalement, l'installation de Fedora 32 est terminée.


Fedora 33 (Server Edition)
Kernel 5.8.15-301.fc33.x86_64 on an x86_64 (ttyS0)

Web console: https://localhost:9090/

localhost login:



Installation Windows Server 2019

Posted by IT NISRO 0 commentaires

 Téléchargez Windows Server 2019 sur le site Microsoft ci-dessous.

                  https://www.microsoft.com/en-us/cloud-platform/windows-server-b/

Pour utiliser Windows Server, achetez-le.

Cependant, il est possible d'essayer d'utiliser la version d'évaluation de Windows Server pendant 180 jours.

Vous pouvez télécharger le fichier ISO de la version d'évaluation à partir du site coup après l'enregistrement de l'utilisateur.

                   https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2019

Installez Windows Server 2019                                             

[1] Insérez le support d'installation de Windows Server et démarrez l'ordinateur. Ensuite, l'écran suivant s'affiche. Cliquez ensuite sur le bouton [Suivant].



[2] Cliquez sur [Installer maintenant] pour démarrer l'installation.



[3] Sélectionnez l'édition du serveur Windows que vous souhaitez installer.

Sur cet exemple, exécuté avec la version [Datacenter with Graphical ***].



[4] Lisez bien les termes de la licence et cochez une case [I acceppt ***] pour continuer.



[5] Pour une nouvelle installation du serveur Windows, sélectionnez [Personnalisé: Installer Windows uniquement].



[6] Sélectionnez une partition pour installer Windows Server.



[7] L'installation de Windows Server démarre. Pendant l'installation, l'ordinateur redémarre automatiquement.



[8] Après le redémarrage de l'ordinateur, l'écran suivant s'affiche, puis Définissez le mot de passe administrateur.



[9] Appuyez sur la touche Ctrl + Alt + Suppr pour vous connecter.


[10] Entrez le mot de passe administrateur que vous avez défini dans la section [8] pour vous connecter.



[11] Connectez-vous simplement à Windows Server. Pour la connexion initiale, la confirmation de configuration des réseaux s'affiche comme suit, sélectionnez Oui ou Non.



[12] Il s'agit du bureau sur Windows Server 2019. L'installation de Windows Server est terminée.



Jenkins - Serveur d'intégration continue

Posted by IT NISRO 0 commentaires

                    A quoi ça sert ?

Intégration continue - Rappel

L'intégration, si on doit le résumé en quelques mots, c'est : "voir les problèmes le plus rapidement possible".

Ce qu'il faut comprendre, c'est que ce concept n'est en aucun cas l'arme absolue contre les défaillances du codes ou du codeurs. Ce qu'il apporte c'est la possibilité de voir les problèmes dès que le codes est écrits et non pas lorsque le code est à quelque jour d'une livraison client par exemple. L'idée étant de voir le comportement de l'ensemble des modules d'un logiciel dans l'environnement de livraison (de préférence) et ainsi voir les problèmes qui peuvent être liés soit à l'environnement soit à des dépendances du code.

Voici comment nous pouvons représenter le cheminement d'un développement :

Sans intégration continueAvec intégration continue

Pour que le processus est un sens, les tests sont très importants. Unitaires et d'intégrations, ils vont être la clé de voûte de la détection des erreurs introduites par les dernières modifications du code.

Les objectifs d'un serveur d'intégration continue

L'intégration continue en elle-même peut très bien être réaliser par une personne, à la main. Cependant cette tâche serai longue et fastidieuse. C'est pourquoi il existe des serveurs pour remplir ce rôle. Nous pouvons voir 3 rôles importants qui sont délégués à ces serveurs :

  • centralisation : permettre à un ensemble de personne de bénéficier d'informations communes.
  • automatisation : permettre d'effectuer l'ensemble des phases de productions (compilation, tests, déploiement...) sans ou avec très peu d'intervention d'un humain.
  • historisation : permettre de garder les productions précédentes et voir l'évolution des productions.

De nombreux produits répondent à ces critères : Hudson/Jenkins, Bamboo (Atlassian), Continuum (Apache), Cruise Control, Luntbuild, Anthill, TeamCity, BuildForge et sûrement d'autres. J'ai choisi de présenter Hudson/Jenkins car j'en ai une expérience pratique assez importante et que j'ai pu voir ces nombreux avantages ainsi que la facilité avec laquelle il est possible de l'intégrer dans un environnement pré-existant.

Comment ça fonctionne ?

Technologie

Jenkins est une application web, développé en java. De ce fait, il est installable sur un grand nombre de système d'exploitation. Avec Jenkins, il est possible d'utiliser un grand nombre d'outils qui ne sont pas intégré directement à Jenkins.

Installations

Type d'installation

Il existe plusieurs manière d'installer Jenkins :

  • serveur d'application web : avec tomcat (par exemple) vous pouvez rapidement mettre en place cette application.
  • standalone : sans utiliser de serveur d'application web, une ligne de commande simple pour exécuter le "war" de jenkins
  • slave : utiliser pour effectuer de la distribution de job et réduire l'utilisation d'un serveur. Chaque slave est rattaché à un et un seul master, mais un master peut avoir un grand nombre de slave. Ne peut se faire qu'à partir d'un jenkins installer en master (l'une des deux méthodes précédente).

Comparatif des installations

Je vais maintenant comparer les installations en "web-app" et en standalone. Je ne peut pas mettre dans le comparatif l'installation slave car son optique est très différente de ces deux installations.

Web-AppStandalone
Avantagesconfiguration pré-établit par le serveur d'application
installation rapide et simple
ne nécessite pas de serveur d'application
plusieurs instances sur un même serveur en utilisant des ports différents
Inconvénientsnécessite un serveur d'applicationdéploiement à grande envergure moins simple

Pour toutes ces installations, il est possible de distinguer le dossier d'installation et le dossier d'utilisation de jenkins. Le dossier d'installation est composé des exécutables et des fichiers de configuration de la plateforme tandis que le dossier d'utilisation est composé des configurations du service. De base, ces deux dossiers sont les mêmes, mais en mettant en place la variables d'environnement HUDSON_HOME il est possible de les séparer. Cette manipulation peut être utile si vous souhaitez que des utiisateurs puissent accèder aux fichiers des jobs, mais pas au war ni à la configuration de jenkins.

La variable d'environnement HUDSON_HOME est un reste du projet Hudson est il se peut que cela change/ai changé depuis l'écriture de ce site.

Installation web-app

Installation standalone

Comment je l'ai dit précédemment, une simple ligne de commande permet démarrer Jenkins :

java -jar jenkins.war

Un certain nombre d'option peuvent être rajouter pour changer les paramètres de base de l'installation :

  • -httpPort : permet de changer le port HTTP sur lequel le service va se mettre en écoute. De base, il est en écoute sur le port 8080
  • -ajp13Port : permet de mettre le service en écoute sur un port AJP, désactivé par défaut. AJP permet par exemple de mettre en place un système de LoadBalancing entre plusieurs instance d'un même service pour assurer de la haute disponibilité.
  • -daemon : pour mettre le service en tâche de fond. Avec ce paramètre, le service mettera tous ses messages de fonctionnement dans un fichier plutôt que dans la fenêtre de commande.

D'autres options existes, mais avec ces trois là vous pouvez accomplirer un grand nombre de choses.

Si vous effectuer cette installation sur un OS Windows, il vous est possible de transformer jenkins en service windows en passant par l'écran d'administration de jenkins.


Installation slave

Comme je l'ai dit précédemment, les slaves sont des instances de Jenkins qui sont rattachées à un master. Pour ce faire, c'est pas très compliqué : Administrer Hudson >> Gérer les noeuds >> Nouveau noeud.

Oui, les instances de Jenkins sont considérés comme des noeuds. D'ailleurs le master est lui aussi un noeud. Si on fait l'analogie avec les arbres informatiques, il s'agit d'un arbre à 1 niveau, le master est la racine, les slaves sont les feuilles. Les slaves ne peuvent avoir de slave

Lors de la configuration de ce nouveau noeud, vous pourrez alors spécifier sont nom, le répertoire dans lequel Jenkins s'exécutera sur l'hôte distant et la manière dont l'instance doit être démarrer. A noter qu'il vous est possible de rajouter un "étiquette" au slave. Cette étiquette permet de faire des pools de slave. Ainsi, les job demandant à s'exécuter sur un hôte windows iront s'éxécuter sur une instance du pool "windows".

Comment s'en sert-on ?

Configuration générale

La configuration général de Jenkins se fait dans "Administrer Jenkins" >> "Configurer le système" :

Informations systèmes

Dans un premier temps, il peut être (c’est sûrement le cas) de vérifier et de configurer le système de Jenkins: sécurité, où se trouve les différents outils, email…

La première chose à vérifier est le dossier d’installation de Jenkins. La première ligne doit donc être le dossier que vous avez défini lors de l’installation. Le nombre d’exécuteur corresponds au nombre de construction qui pourront être faite en parallèle. La période d’attente corresponds au temps que doit attendre un « job » entre le moment où il est déclenché et le moment où la construction commence réellement.

Gestion de la sécurité

Ici le plus important peut être la sécurité (comme pour tout). Avant toute configuration, tout le monde peut créer/configurer/exécuter/voir/supprimer un job et le contenu de l’espace de travail du job. Afin d’éviter cela, vous devez mettre en place des règles de sécurité pour que ces actions ne soit possible que pour cette personne.

Activez la sécurité, choisissez la base de donnée d’utilisateur que vous souhaitez utiliser. Dans le cas d’utilisation d’un Jenkins « isolé », prenez simplement la base de donnée de Jenkins. Pas de panique, il n’est pas nécessaire d’installer une base oracle ou MySQL en supplément. Il est également possible de caller votre Jenkins avec un serveur LDAP et même d’utiliser les groupes de votre LDAP. Ici, je vais uniquement vous parler de la configuration avec la « base de données » intégré dans Jenkins.

Dans un premier temps, laissez coché le champs pour laisser les utilisateurs s’inscrire. Sauvegarder votre configuration.

Inscrivez un nouvel utilisateur, admin par exemple, qui aura tous les droits. Retournez dans la configuration du système et décochez la case d’inscription. En faisant cela, vous vous assurez que vous seul pourrez ajouter les personnes que vous désirez. Ensuite, vous devez choisir la méthode d’autorisation que vous souhaitez utiliser:

  • matrice: vous accordez certains droits aux utilisateurs enregistré dans la base de Jenkins. L’attribution des droits se fait utilisateur par utilisateur.
  • autorisez tous les utilisateurs enregistré à tout faire. Comme vous seul pouvez enregistrer de nouveau utilisateur, cela semble correcte mais vous pouvez vouloir distinguer un utilisateur d’un autre (dans ce cas, retour à la matrice).
  • si vous laissez « tout le monde peut tout faire » alors vous ne gérez pas la sécurité..
  • vous pouvez choisir une matrice qui dépend de chaque projet. Utile si un même utilisateur ne doit pas avoir les mêmes droits d’un projet à un autre.
  • le mode legacy distingue les admins des autres. Les admins peuvent tout faire, les autres rien.

Configuration des outils tiers

Par la suite, vous devez configurez les outils de construction de projet (Ant, Maven, JDK, G++, SVN, Mercurial…) pour que Jenkins puisse les trouver et les utiliser.

Tout ce que vous avez besoin de renseigner dans cette catégorie, c'est l'emplacement des exécutables que vous souhaitez pouvoir utiliser. De base, vous devrez indiquer l'emplacement d'un JDK, de Maven, de Ant. Avec l'installation de quelques plugins, vous pouvez mettre mercurial en plus par exemple.

Biensûr, il est possible de demander à Jenkins de télécharger et d'installer ces outils pour vous. Comme ça vous n'avez pas besoin d'avoir les droits d'administration sur la machine hôte. A noté, qu'il faut tout de même que Jenkins ai ces droits sur la machine hôte, donc qu'il est été démarré par un administrateur.

Si toute fois, vous utiliser un outil externe qui n'a pas d'équivalent en plugin (PLink, putty...) et que vous avez besoin d'effectuer des lignes de commande avec cet outil, il est possible de mettre en place une propriété global dans Jenkins. Cette propriété va agir comme une variable d'environnement mais ne touchera que Jenkins. Vous pourrez donc appeler un exécutable facilement (sans avoir besoin de mettre la chemin d'accès complet).

Gestion des plugins

Hudson vous permet d’accéder à une bibliothèque d’extensions (plugins) assez très conséquente.

L'installation d'un plugin est très simple : choisir, cocher, cliquer, utiliser. Par ici le chemin : "Administrer Jenkins" >> "Gestion des plugins"

Choisir les plugins qui vous intéresse :

En bas de la page, vous trouverez le bouton pour installer votre sélection de plugins. Un petit redémarrage de Jenkins et s'est bon, vous pouvez les utiliser.

La mise à jour des plugins est très simple également : c'est presque la même manipulation. La différence étant d'aller dans l'onglet "mise à jour" plutôt que dans "disponible".

Création et configuration d'un job

Jenkins vous permet de pouvoir configurer un nombre infini de Job. Chaque job est une configuration de production pour un projet : le même projet peut avoir plusieurs job.

C'est plutôt bien expliqué : juste comprendre que un "free-style" permet de TOUT faire, un maven2/3 permet de produire des projets sous maven et la copie de job existant permet que si vos projets sont identiques en terme d'exécution alors vous pouvez ne pas vouloir tout refaire (surtout si c'est long), Jenkins le fait pour vous.

L'écran ci-dessus montre les propriétés qu'il est possible de mettre sur chaque job. Ces paramètres sont les premières choses consultés par Jenkins lorsqu'il doit construire le projet. Ces paramètres ne corresponde pas réellement à ce que Jenkins doit faire mais comment il doit se comporter.

L'écran ci-dessus montre comment Jenkins doit récupérer le code du projet. De base, il gère CVS et Subversion (SVN). Des plugins existe pour la plupart des autres grands outils du domaine : Git, Mercurial, Bazaar, ClearCase...

L'écran ci-dessus permet de spéficier quand ou pourquoi le job doit se lancer. Ainsi on retrouve des CRON, il est également possible de lancer des builds successivement. A noter que "Construire périodiquement" et "Scruter l'outil de gestion de version" sont tous deux des CRON mais l'un va forcer la construction, tandis que l'autre ne va le faire que si un changement dans le code à été fait.

Dans un job de type "maven", une autre option est disponible : "construire à la suite de dépendances SNAPSHOT". Les dépendances sont automatiquement récupérées grâce au fichier POM. On arrive alors à avoir un vrai fonctionnement d'intégration continue : si une des dépendances à changer (nouveau code, correction, nouvelle feature..) alors il est important de vérifier que ces changement non pas altéré le fonctionnement de mon code, même si mon projet n'a pas changé entre temps.

Comme nous sommes dans un job "free-style", nous pouvons choisir ce que nous souhaitons faire. De base, on peut effectuer des commandes windows (batch), *unix (shell), ant et maven. Des plugins viennent compléter ces possibilités (python..) mais avec ces 4 là, il est déjà possible de faire pas mal de choses.

J'ai donc choisi de faire une commande shell puis d'appeler des goal mavens. Il est possible de mettre autant de fenêtre de construction que l'on souhaite.

Ensuite on effectue la configuration de ce que Jenkins doit faire une fois la construction du projet terminée. On y retrouve l'analyse des résultats de tests, archiver les livrables créés, mettre à disposition la javadoc directement depuis la page du job... Toutes ces configurations permettent de mettre en place un rendu visuel sur la page du job comme présenté un peu plus bas.

Voilà la configuration possible d'un job "free-style". Comme vous pouvez le voir, il est possible d'y appeler des goals maven.

Distribution de job

Afin de faire de la distribution de Job, nous avons besoin d'au moins un slave opérationnel. Lorsque un slave est configuré sur le master, il est possible de mettre en place une règle dans la configuration du job pour que l'exécution soit déporté sur un slave particulier ou sur une famille de slave.

La valeur peut être le nom exact du slave que vous visez, une étiquette de slave (défini à la création des slaves) ou une expression régulière ou conditionnelle.

Résultats

Une fois votre job confguré comme vous le souhaitez, Jenkins vous permettra d'obtenir des courbes de tests, d'analyse statique de votre code, un historique des productions effectué. Et le tout de manière claire et simple.

Ci-dessus, nous avons la page du job. Elle permet d'avoir les informations concernant ce projet : évolution des tests, évolution des constructions, divers lien vers la documentation, rapport d'analyse...

Ci-dessus est représenté la page d'un build. Jenkins nomme un "build" une construction d'un job. Nous pouvons y voir ce qui à délenché le build, les modifications par rapport au build précédent, si il a réussi ou non...

De plus, grâce à l'historisation des builds précédent, Jenkins permet de noter tout changement de comportement du projet. Ainsi un test qui ne fonctionne pas sera noté "Failed" mais un test qui ne fonctionne plus (par rapport au build précédent) sera noté "Regression".

Une réussite est de couleur bleu car le création est Japonnais. Les feux tricolore y sont bleu-orange-rouge. D'où la couleur bleu. Toute fois, si cela vous choque, il existe un plugin pour mettre du vert à la place. Cependant, cela n'affectera pas les graphiques de tests, mais uniquement les boules de status de build.

Un peu plus loin

Enchainement des jobs

Afin d'entrer dans un processus d'intégration continue, il est important de pouvoir construire des projets les uns après les autres. Jenkins permet de faire cette configuration.

Ainsi, dans un job de type free-style, il est possible de préciser à la main les jobs qui doivent s'effectuer avant et/ou après. Pour un job de type "maven" il est possible de spécifier déclencher un build lorsqu'une dépendances snapshot est construite.

Les plugins

Le fonctionnement de base de Jenkins permet à la plupart des projets de pouvoir l'utiliser directement. Cependant, il existe plus de 140 plugins qui permettent à Jenkins d'augmenter ces capacités. Ainsi il existe des plugins pour pouvoir utiliser des outils de gestion de version (mercurial, git..), des plugins pour améliorer la présentation de résultats...

Voici la liste complète des plugins: http://wiki.jenkins-ci.org/display/JENKINS/Plugins


Followers

Formulaire de contact

Nom

Adresse e-mail *

Message *