[ArchLinux] Paquet invalide ou corrompu : réparer Pacman

Dernièrement, j’ai rencontré un problème à la mise à jour d’un ordinateur sous Arch. L’erreur indiquait: « la préparation de la transaction a échoué (paquet invalide ou corrompu) ».

$ sudo pacman -Syu
 :: Synchronisation des bases de données de paquets...
 core est à jour
 extra est à jour
 community est à jour
 :: Début de la mise à jour complète du système...
 erreur : l’ouverture du fichier /var/lib/pacman/local/blender-17:2.78-1/desc a échoué : Aucun fichier ou dossier de ce type
 résolution des dépendances...
 recherche des conflits entre paquets...
 avertissement : les métadonnées pour le paquet blender-17:2.78-1 n’ont pas pu être totalement chargées.
 erreur : la préparation de la transaction a échoué (paquet invalide ou corrompu)

La première étape pour que Pacman accepte d’effectuer la mise à jour du système consiste à retirer le paquet posant problème, ici blender.

sudo pacman -R blender

Une fois le paquet retiré, on peut procéder à la mise à jour.

sudo pacman -Syu

Ou pas, puisque j’obtiens cette fois des erreurs de conflits de fichiers :

erreur : la validation de la transaction a échoué (conflit de fichiers)
 ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf est déjà présent dans le système de fichiers
 ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf est déjà présent dans le système de fichiers
 ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf est déjà présent dans le système de fichiers
 ttf-dejavu : /etc/fonts/conf.d/57-dejavu-sans-mono.conf est déjà présent dans le système de fichiers
 ttf-dejavu : /etc/fonts/conf.d/57-dejavu-sans.conf est déjà présent dans le système de fichiers
 ttf-dejavu : /etc/fonts/conf.d/57-dejavu-serif.conf est déjà présent dans le système de fichiers
 Des erreurs se sont produites, aucun paquet n’a été mis à jour.

Dans ce cas précis, la procédure à suivre consiste à vérifier pour chaque fichier, si celui-ci est utilisé par l’un des paquets du système.

$ sudo pacman -Qo /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf
 erreur : aucun paquet ne contient /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf

Une fois assuré que le fichier est inutilisé, on le renomme pour en conserver un exemplaire, au cas où. D’après la documentation, celui-ci sera nettoyer lors de la mise à jour.

$ sudo mv /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf.save

Une fois ces opérations effectuées pour chacun des fichiers posant problème, on peux relancer à nouveau le processus de mise à jour.

sudo pacman -Syu

Cette fois, les paquets sont mis à jour correctement, tant mieux! En me basant sur ce que j’ai lu, il semble que l’erreur « paquet invalide ou corrompu » apparaisse dans différents cas de figure. Si l’erreur devait réapparaître, il n’est donc pas exclu de devoir trouver une autre solution pour la résoudre.

Générer un fichier PDF sur clic dans une servlet avec BIRT – Maven – Netbeans

Avant-propos

Cet article va présenter une technologie complémentaire (BIRT) utilisée dans le cadre d’un projet de gestion de cours en ligne fait en TP de Java à l’UTBM.

BIRT (The Business Intelligence and Reporting Tool) est un projet de la communauté Eclipse comprenant un générateur de rapports, un générateur de graphique ainsi qu’un environnement de conception. Heureusement pour nous il n’est pas nécessaire de développer sur Eclipse pour l’utiliser. Mais il vous faudra tout de même installer le BIRT report designer que vous pouvez trouver sur cette page.

Prérequis

Le BIRT report designer est nécessaire pour la génération d’un fichier .rptdesign qui vous sera demandé par la suite.

Ajout de la bonne dépendance (org.eclipse.birt.runtime) dans le fichier pom.xml de votre projet que vous pouvez trouver ici par exemple.

Tutoriel : Générer un fichier PDF sur clic dans une servlet avec BIRT

Les deux classes suivantes sont à ajouter dans votre projet.

Ainsi vous avez la première classe appelée par la servlet et permettant de démarrer le Report Engine.

public class BirtEngine {

    private static IReportEngine birtEngine = null;

    private static Properties configProps = new Properties();

    private final static String configFile = "BirtConfig.properties";

    public static synchronized void initBirtConfig() {
        loadEngineProps();
    }

    public static synchronized IReportEngine getBirtEngine(ServletContext sc) {
        if (birtEngine == null) 
        {
            EngineConfig config = new EngineConfig();
            if( configProps != null){
                String logLevel = configProps.getProperty("logLevel");
                Level level = Level.OFF;
                if ("SEVERE".equalsIgnoreCase(logLevel)) 
                {
                   level = Level.SEVERE;
                } else if ("WARNING".equalsIgnoreCase(logLevel))
                {
                   level = Level.WARNING;
                } else if ("INFO".equalsIgnoreCase(logLevel)) 
                {
                   level = Level.INFO;
                } else if ("CONFIG".equalsIgnoreCase(logLevel))
                {
                   level = Level.CONFIG;
                } else if ("FINE".equalsIgnoreCase(logLevel)) 
                {
                   level = Level.FINE;
                } else if ("FINER".equalsIgnoreCase(logLevel)) 
                {
                   level = Level.FINER;
                } else if ("FINEST".equalsIgnoreCase(logLevel)) 
                {
                   level = Level.FINEST;
                } else if ("OFF".equalsIgnoreCase(logLevel)) 
                {
                   level = Level.OFF;
                }

                config.setLogConfig(configProps.getProperty("logDirectory"), level);
            }

            IPlatformContext context = new PlatformServletContext( sc );
            config.setPlatformContext( context );


            try
            {
                Platform.startup( config );
            }
            catch ( BirtException e )
            {
                e.printStackTrace( );
            }

            IReportEngineFactory factory = (IReportEngineFactory) Platform
                .createFactoryObject( IReportEngineFactory.EXTENSION_REPORT_ENGINE_FACTORY );
            
            birtEngine = factory.createReportEngine( config );
        }
        return birtEngine;
    }

    public static synchronized void destroyBirtEngine() {
        if (birtEngine == null) {
            return;
        }  
        birtEngine.shutdown();
        Platform.shutdown();
        birtEngine = null;
    }

    public Object clone() throws CloneNotSupportedException {
        throw new CloneNotSupportedException();
    }

    private static void loadEngineProps() {
        try {
            //Config File must be in classpath
            ClassLoader cl = Thread.currentThread ().getContextClassLoader();
            InputStream in = null;
            in = cl.getResourceAsStream (configFile);
            configProps.load(in);
            in.close();
        } catch (IOException e) {
            e.printStackTrace();
        }
    }
}

La classe de la servlet que vous appellerez pour générer votre fichier pdf.

public class WebReportServlet extends HttpServlet {

    private static final long serialVersionUID = 1L;

    private IReportEngine birtReportEngine = null;
    protected static Logger logger = Logger.getLogger( "org.eclipse.birt" );

    public WebReportServlet() {
        super();
    }

    @Override
    public void destroy() {
        super.destroy(); 
        BirtEngine.destroyBirtEngine();
    }


    @Override
    public void doGet(HttpServletRequest req, HttpServletResponse resp)
      throws ServletException, IOException {

        resp.setContentType( "application/pdf" ); 
        resp.setHeader ("Content-Disposition","inline; filename=test.pdf");  
        
        String reportName = "test.rptdesign";
        String param1 = req.getParameter("param_1");
        ServletContext sc = req.getSession().getServletContext();
        this.birtReportEngine = BirtEngine.getBirtEngine(sc);

        IReportRunnable design = null;
        try
        {
            //Open report design
            design = birtReportEngine.openReportDesign( sc.getRealPath("/Reports")+"/"+reportName );
            
            //create task to run and render report
            IRunAndRenderTask task = birtReportEngine.createRunAndRenderTask( design );  
            
            int parameter1 = 0;
            try{
                parameter1 = new Integer(param1);
            } catch (Exception e){
                parameter1 = 0;
            }
            if(parameter1 >= 1){
                task.setParameterValue("param_1", parameter1);
            }
            else{
                task.setParameterValue("param_1", 0);
            }
            
            //set output options
            HTMLRenderOption options = new HTMLRenderOption();
            options.setOutputFormat(HTMLRenderOption.OUTPUT_FORMAT_PDF);
            options.setOutputStream(resp.getOutputStream());
            task.setRenderOption(options);

            //run report
            task.run();
            task.close();
        } catch (Exception e){
            e.printStackTrace();
            throw new ServletException( e );
        }
    }

    @Override
    public void doPost(HttpServletRequest request, HttpServletResponse response)
      throws ServletException, IOException {

    }
}

Assurez vous d’avoir mappé votre servlet correctement ici le mappage est réalisé dans le fichier web.xml comme ceci :

    <servlet>
        <servlet-name>birtServlet</servlet-name>
        <servlet-class>
            com.coursenligne.servlet.WebReportServlet
        </servlet-class>
    </servlet>
    <servlet-mapping>
        <servlet-name>birtServlet</servlet-name>
        <url-pattern>/birt</url-pattern>
    </servlet-mapping>

Dans le cas présent l’appel à l’adresse suivante via votre navigateur…

http://localhost/webapp/birt?param_1=1

… ne vous donnera pas le résultat escompté, en cause la ligne suivante :

design = birtReportEngine.openReportDesign( sc.getRealPath("/Reports")+"/"+reportName );

Le design en question est un fichier. Celui dont je vous parlais plus tôt au format .rptdesign. Il est à placer dans le répertoire cible (Attention : le placement de votre dossier de placement déterminera aussi la visibilité des documents contenus, voir visibilité de WEB-INF).

Heureusement pour vous, après vérification on peut voir que le mot de passe de votre base de données est chiffré. Moins d’inquiétude donc si l’on tombait par hasard sur votre fichier de design.

<encrypted-property name="odaPassword" encryptionID="base64">Y291cnM=</encrypted-property>

Comme vous l’avez peut-être constaté vous ne pouvez exécuter le code précédent, et pour cause il vous faut générer le fichier de design. Prochaine étape donc, le BIRT report designer qui se présente comme ci-dessous.

Rien de bien nouveau pour ceux qui utilisent régulièrement toutes sortent d’IDE. Pour accéder à vos données (Data Source) vous aurez plusieurs choix, cliquez sur l’onglet « Data Explorer » dans la colonne de gauche. Puis clic droit sur « Data Sources » et « New Data Source » plusieurs choix s’offrent à vous.

Ici pour une question de simplicité j’ai choisi d’utiliser « JDBC Data Source », ajoutez y les paramètres de connexion à votre base de données. Ensuite créez un Data Set qui va vous permettre de récupérer le précieux sésame (vos données).

La clause where présente va ajouter un param dans « Parameters »

Si vous voulez que la génération de votre fichier pdf prenne en compte un paramètre passé dans la barre de recherche éditez simplement la ligne en activant « Linked To Report Parameter » comme ceci :

Voilà vous êtes fin prêt à générer votre fichier pdf, il suffit d’ajouter un bouton pointant sur la bonne URL avec les bons paramètres !

En conclusion

Les deux grandes difficultés que j’ai pu rencontrer lors de la mise en place de la génération automatique de PDF à l’aide de BIRT a été la vieillesse des résultats retournés par les moteurs de recherches. L’âge du projet BIRT en est la cause (de 2005 à maintenant). La deuxième difficulté a été de comprendre que le .rptdesign est obligatoire pour générer un pdf même si nous voulons le générer de manière programmatique. Un dernier point noir est la difficulté de trouver une documentation BIRT digne de ce nom.

L’opinion neutre est que l’utilisation du BIRT report designer par un informaticien n’est pas la chose la plus ancrée dans ses gênes bien que vous ayez des tonnes de paramètres très proches du HTML/CSS on est dans notre droit de demander si ils n’auraient pas pu intégrer directement les mêmes balises dans les .rptdesign au lieu de faire à leur sauce et nous obliger à utiliser le designer.

Les points positifs sont la facilité à postériori (une fois la technologie domptée) de générer un fichier pdf par simple clic dans notre application avec les données directement trouvées dans notre base de données.

J’avais utiliser FPDF en PHP pour la génération de facture automatique en stage de fin d’IUT et j’avais trouvé l’utilisation / intégration dans ne application existante très facile. Dans le cas de FPDF toute la génération est programmée en PHP un vrai plus si vous êtes développer et que la tâche à réaliser est bien définie et ne changera pas tous les 10 du mois. A l’inverse, mon utilisation de BIRT me laisse porter à croire que son utilisation au sein d’une moyenne ou grande entreprise est fort appréciable, avec quand même dans l’obligation de maitriser correctement le BIRT report designer et ses nuances ! Un petit avantage aussi pour la modification d’un design déjà existant, vous voulez ajouter une image ? Importer la dans le designer et glisser la à l’endroit souhaité (Quid par contre de la mise en page qu’il faudra revoir mais au moins ici vous avez un retour visuel direct).

Code source inspiré de : Wiki officiel BIRT servlet

 

Apache, WordPress et redirections

Pour bien commencer l’année 2017, j’ai décidé de remettre le nez dans la configuration Apache du site. Lorsque j’avais installé WordPress pour créer Unicoda en 2012, j’avais renseigné les deux paramètres « Adresse web de WordPress (URL) » et « Adresse web du site (URL) » dans les réglages généraux avec « http://www.unicoda.com ». Du côté de la conf Apache, j’avais indiqué que le serveur répondrai avec le contenu du WordPress pour unicoda.com et www.unicoda.com bien entendu.

Un beau jour, j’ai fini par remarquer qu’en tentant d’accéder au site via unicoda.com, j’étais redirigé vers www.unicoda.com. Cette redirection étant effectuée par WordPress lorsque celui-ci constate que l’url ne correspond pas à l’adresse configurée. Autant vous dire que celle-ci n’était pas des plus rapides. J’ai donc décidé en ce début d’année d’améliorer le processus de redirection en l’effectuant directement au niveau d’Apache.

En modifiant mes fichiers de configuration, j’ai donc ajouté une redirection de unicoda.com vers www.unicoda.com sur les deux protocoles http et https. Désormais, j’ai donc un virtualhost spécifique pour unicoda.com, en lieu et place d’une déclaration comme « ServerAlias » de www.unicoda.com dans un seul fichier de configuration. Le résultat est sans appel puisque la redirection prend désormais 100 ms environ alors qu’elle était de l’ordre de la seconde avant. Si je me base sur un test effectué via gtmetrix, on passe de 2,57 s à 325 ms, presque un facteur 8 (7,9) ! Le gain en rapidité n’est donc pas négligeable.

Pour ce qui est de la redirection http, la configuration est relativement simple :

<VirtualHost *:80>
    ServerName unicoda.com
    Redirect permanent / http://www.unicoda.com
</VirtualHost>

Et enfin, cerise sur le gâteau, l’opération s’est déroulé sans accro après rechargement de la nouvelle configuration par le processus Apache. En  somme, c’est donc une année 2017 qui commence plutôt bien.

Pourquoi j’ai migré ma boîte mail

Pendant longtemps, mon adresse mail principale a été gérée par le FAI de la famille; une adresse en @neuf.fr en l’occurrence. J’ai jonglé et jongle encore entre plusieurs adresses mails, en fonction des cas et des besoins. Je crois que j’ai pris conscience de l’importance de l’adresse mail que l’on communique (la principale, pas celle pour le spam), le jour où, en pleine recherche de stage, le serveur mail de mon école d’ingénieur s’est écroulé et est resté inaccessible pendant une petite semaine. Pas terrible, lorsque l’adresse mail qui figure sur votre CV retourne un mail d’erreur technique. On reste heureusement joignable par l’intermédiaire plus traditionnel du téléphone. Bref, dans les deux jours qui suivaient, j’avais changé l’adresse mail de mon CV par mon adresse principale FAI.

Et voilà qu’il y a de cela deux années, la question est revenue sur le devant la table. Après avoir repris le contrôle sur un certain nombre de mes données en hébergeant mes propres services, je me suis tourné vers le problème de l’adresse mail. Il faut savoir qu’en France, une adresse FAI n’est pas immuable. Tant qu’on reste chez ce FAI, pas de problème, mais dès lors que l’on résilie son abonnement, les risques apparaissent. En effet, en cas de résiliation, le fournisseur a l’obligation légale de maintenir l’accès à l’adresse pour une durée de 6 mois. Après 6 mois, la décision de conserver l’adresse mail ou de la supprimer pour pouvoir la réattribuer est à la discrétion de l’opérateur. En règle générale, les pratiques diffèrent donc d’un fournisseur à l’autre, certains garantissent la pérennité de l’adresse sans limite de temps, d’autres avec condition « d’activité » par période de 6 mois. Il est donc préférable d’éviter d’utiliser une adresse mail FAI comme adresse principale de contact, sachant que l’on peut être amené à changer de fournisseur pour l’une ou l’autre raisons.

Se pose également la question de la confiance. Bien évidemment, les mails que nous envoyons transitent en clair sur le réseau, et si les communications peuvent être éventuellement chiffrés entre les serveurs par lesquels le mail passera, celui-ci reste en clair au niveau de chaque serveur le temps d’être transféré vers le serveur suivant. On s’intéresse davantage ici à la confidentialité des données. En clair, dans quelle mesure faisons-nous confiance à l’hébergeur de notre adresse pour que celui-ci ne consulte pas le contenu de nos mails entrants et sortants; comme le fait Google à l’aide d’algorithmes pour proposer de la publicité ciblée dans son interface web ?

Ayant réfléchi à de nombreuses reprises, à l’hébergement de mon propre serveur mail, mais l’ayant toujours repoussé pour divers raisons (relative complexité, gestion du spam, mise en liste blanche de l’IP du serveur, redondance en cas de panne ou d’indisponibilité…), je me suis tourné vers une solution intermédiaire : prendre un nouveau nom de domaine chez un hébergeur proposant une solution mail associée. Ainsi, j’obtiens le premier maillon, le nom de domaine et peux par la suite rediriger les mails vers mon propre serveur. J’ai donc enregistré un nom de domaine chez Gandi puisque leur offre inclut la possibilité de créer 5 boîtes mail pour 1Go d’espace total partagé, redirection, alias, antivirus et anti-spam, avec possibilité de passer sur une offre payante spécifique pour le mail. Cette solution permet également d’envisager si nécessaire, le passage vers une offre payante chez ProtonMail, avec gestion de nom de domaine personnalisé.

Voici quelques points que j’ai noté pour mon changement d’adresse mail :

  • Ne pas se précipiter, prendre son temps. Cela ne sert à rien d’espérer tout changer en quelques jours, il faudra du temps pour s’assurer que nos contacts utilisent notre nouvelle adresse.
  • Migrer progressivement tous les comptes vers la nouvelle adresse. En effectuant la migration sur plusieurs mois, on constate au fur et à mesure quels services ne disposent pas de la nouvelle adresse.
  • Éventuellement et si possible, mettre en place un message de réponse automatique sur l’ancienne adresse pour indiquer le changement d’adresse.

Par ailleurs, ce travail de migration se trouve grandement simplifié lorsqu’on possède déjà la liste de ses comptes dans un Keepass ou équivalent. On connaît alors tous les endroits où le changement d’adresse est à effectuer; mais en contrepartie, toutes les entrées utilisant l’ancienne adresse sont à mettre à jour.

La question essentielle à se poser me semble être : « A qui puis-je faire confiance pour gérer mes mails et dans quelle mesure ? ».

PS: Reste toujours le même problème que si l’un de nos contacts à son adresse chez un fournisseur auquel nous ne faisons pas confiance, celui-ci dispose tout de même d’une copie de nos échanges. (A moins de chiffrer évidemment).

[WordPress] Désactivation des polices d’écriture Google

J’y pensais depuis un certain temps, ce soir c’est chose faite : les polices d’écriture ou « Google Fonts » sont à présent désactivées sur ce WordPress. Désormais, plus de requêtes vers Google pour récupérer ces éléments à chaque visite.

La manipulation est simple à effectuer, il suffit d’installer l’extension « Disable Google Fonts » et l’effet est alors immédiat.

Si je regarde les chargements externes encore présent sur Unicoda, je trouve Gravatar, bien évidemment, et Youtube lorsque j’ajoute une vidéo à un billet. Pour Gravatar, la solution me semble relativement simple, soit je désactive la fonctionnalité, soit je trouve un plugin permettant de mettre en cache côté serveur les images issues de Gravatar. Pour les vidéos, c’est à première vue plus compliqué si on souhaite garder l’intégration et ne pas remplacer celle-ci par un simple lien sur la page. Bref, des sujets périphériques à creuser, mais qui touche à la surveillance indirecte imposée aux utilisateurs par le chargement d’éléments externes.