Simon Vieille

Gitnet est la forge logicielle que je gère depuis quelques années et qui héberge la totalité de mes projets. Elle s'appuie sur l'excellentissime Gitea, un logiciel libre pour faire son propre Github/Gitlab sans dépenser des fortunes en ressources matérielles.

Gitea est un logiciel très complet mais une des fonctionnalités qui peut manquer à certain⋅e⋅s est la publication pages web statiques via la forge. Codeberg a développé Codeberg/pages-server, un projet écrit en GO qui permet de réaliser cette fonctionnalité. Il lance un serveur web et sert les fichiers qui sont récupérés via l'API. Après l'avoir forké pour le personnalisé, il est à présent déployé sur Gitnet Pages.

Pour commencer à publier, vous devez créer un dépot pages dans lequel vous déposerez y vos fichiers. Le contenu sera accessible via https://votre-login.gitnet.page/{fichier}.

Dans le cas où vous souhaitez intégrer des pages à un dépot existant, ajoutez une branche pages puis accédez à votre contenu via https://votre-login.gitnet.page/le-depot/{fichier} :

dev@project $ git switch --orphan pages
# Si vous avez des fichiers ignorés par git qui existent :
dev@project $ git rm --cached -r .

Et si vous désirez accéder à du contenu qui se trouve sur une autre branche, il faudra la spécifier de cette façon : https://votre-login.gitnet.page/le-depot/@la-branche/{fichier}.

Vous pouvez utiliser un générateur de site static mais il faudra ajouter un CI/CD. J'ai réalisé des tests avec Hugo + Woordpecker et ça marche bien ! On build la branche ou se trouve les sources, on copie le résultat dans la branche pages et on pousse le code sur Gitnet. Voici la configuration utilisée.

Si toutefois le service venait à être pas mal utilisé, alors j'intégrerai des fonctionnalités plus avancées comme le nom de domaine personnalité. Tel qu'il est déployé actuellement, ce n'est pas possible.

Gitea est l'une des briques majeures de mon informatique puisque c'est le logiciel qui gère l'ensemble de mes projets de développement.

Dès la version 1.17, il sera possible d'utiliser Gitea comme registre de paquets. Ce registre est compatible avec les principaux gestionnaires de paquets du marché : composer, npm, pip, gem, conan, nuget, …

Cette nouvelle fonctionnalié est géniale car elle permet d'avoir un seul et unique outil qui fait office de registre, quelque soit le type de langage. Les paquets et le code source sont au même endroit donc on se disperse moins. Enfin, on contribue à décentraliser l'hébergement de paquets, ce qui peut radicalement réduire le coût énergétique et les ressources réseaux nécessaires pour tester/builder/installer/déployer un logiciel.
Dans mon cas d'usage, j'ai des projets avec une CI/CD qui repose sur docker et des images persos. Pendant un build, les images seront téléchargées depuis mon réseau local donc ça sera bien plus vite.

J'ai testé plusieurs types de paquets et ça fonctionne très bien ! La documentation est disponible ici.

Bravo aux développeur⋅euses de Gitea qui font un boulot monstrueux 💚

Au moment où j'ai commencé à utilisé Wireguard, je me suis aperçu que le principal usage que j'en ferais serait le DNS.

Sur l'ensemble de mes périphériques (ordinateurs, smartphones, serveurs), j'apporte une grande attention à la protection de ma vie privée. Mon informatique n'est pas parfaite mais j'essaye de faire de mon mieux en ajustant la sécurité des services, la protection des données et le confort des outils.
À ce titre, j'utilisais Blockada sur mon smartphone. Cette application permet (principalement) de modifier les DNS utilisés sur votre smartphone. Si on choisi un DNS qui opère du filtrage, alors on peut réduire l'affichage des publicités ou bloquer l'accès à des services malveillants. Mais je devais nécessairement passer par un DNS public que je ne peux pas configurer.

Lors de la configuration d'un accès via Wireguard, on peut spécifier un DNS à attribuer au périphérique. J'ai donc mis en place un DNS redondant dans mon réseau privé, accessible aussi via mon réseau VPN Wireguard. J'ai choisi d'utiliser l'application AdGuard et j'ai ajouté quelques listes pour réaliser du filtrage. Tout mon réseau privé et mes périphériques connectés au VPN bénéficient de ces DNS privés. Que je sois chez moi ou en itinérance, mes filtres DNS sont appliqués et mon traffic mobile passe systématiquement dans mon VPN.

En complément de ce DNS, j'utilise l'extension uBlock Origin et je dois dire que la combo est vraiment efficace. C'est extrèment rare de voir de la publicité et ma navigation est selon moi plus sécurisée. Si toutefois uBlock ne bloque pas une requête, alors le DNS prend le relais et fait le reste du ménage.

Sur les 30 dernières jours, le DNS principal a réalisé 1,3 millions de résolutions et en a bloqué près de 43 milles. En moyenne, 3 à 5% des requêtes DNS sont filtrées, ce qui représente environ 500 domaines qui délivrent majoritairement de la publicité et de la télémétrie.

Murph est un framework open-source pour construire des CMS. Il est développé à l'aide de Symfony et permet de gérer des sites web avec plusieurs noms de domaines et en plusieurs langues.

Cet article fait partie d'une série de tutoriaux pour présenter les fonctionnalités de Murph.

Contrairement à pas mal de CMS, une page permet de rassembler des contenus qui pourront être réutilisés plusieurs fois dans une arborescence, là où certains CMS lient définitivement une page à un élément du menu.

Par ailleurs, une page ne contient que des données qui pourront être présentées comme on le veut. Autrement dit, la manière de rendre une page est indépendante de la façon de rédiger les contenus.

On va créer une nouvelle page ExamplePage avec ces contenus :

• un titre title qui sera un champ texte
• un bloc de contenu content avec l'éditeur TinyMCE

On va ensuite enregistrer la page dans Murph et lui donner le nom Page d'exemple.

core:
    site:
        # ...
        pages:
            App\Entity\Page\ExamplePage:
                name: "Page d'exemple"
                templates:
                    - {name: "Default", file: "page/example/default.html.twig"} 

Quand une page est créée, un template par défaut l'est aussi. Une page peut avoir autant de templates qu'on souhaite.

Éditons le template par défaut pour afficher simplement nos contenus :

{% extends 'base.html.twig' %}

{% block page %}
    <h1>{{ _page.title.value }}</h1>

    {{ _page.content.value|raw }}
{% endblock %}

On peut à présent créer un nouvel élément dans le menu, lui attribuer une nouvelle page et commencer à saisir le contenu.

La documentation complète est disponible sur doc.murph-project.org.

Murph est un framework open-source pour construire des CMS. Il est développé à l'aide de Symfony et permet de gérer des sites web avec plusieurs noms de domaines et en plusieurs langues.

Je vais entamer une série de tutoriaux pour présenter les fonctionnalités de Murph.

Cet article va pour expliquer comment utiliser Murph et générer des interfaces de CRUD afin de créer, voir, mettre à jour et supprimer des entités.

Dans un premier temps, il faut créer une nouvelle entité Example. Si vous avez déjà réaliser cette opération, vous pouvez passer à l'étape suivante.

dev@project $ php bin/console make:entity Example

j'ai décidé d'ajouter ces attributs :

• label de type string obligatoire
• content de type text obligatoire

On doit maintenant éditer App\Entity\Example et implémenter l'interface App\Core\Entity\EntityInterface :

<?php

namespace App\Entity;

use App\Core\Entity\EntityInterface;
use App\Repository\ExampleRepository;
use Doctrine\ORM\Mapping as ORM;

/**
 * @ORM\Entity(repositoryClass=ExampleRepository::class)
 */
class Example implements EntityInterface
{

Puis il faut mettre à jour la base de données :

dev@project $ make doctrine-migration

Ensuite on va générer :

• le générateur de requête App\Repository\ExampleRepositoryQuery
• la fabrique App\Factory\ExampleFactory
• le formulaire d'édition App\Form\ExampleType

dev@project $ php bin/console make:repository-query ExampleRepository
dev@project $ php bin/console make:factory ExampleFactory Example
dev@project $ php bin/console make:form ExampleType Example

Générons à présent le CRUD :

dev@project $ php bin/console make:crud-controller \
  ExampleAdminController \
  Example \
  ExampleRepositoryQuery \
  ExampleFactory \
  ExampleType

Enfin, ajoutons le lien dans le menu du backoffice :

{{ include('@Core/admin/module/_menu_section.html.twig', {label: 'My section'}) }}

<ul class="nav flex-column">
    {{ include('@Core/admin/module/_menu_item.html.twig', {
        id: 'example',
        label: 'Examples',
        route: path('admin_example_index'),
        icon: 'fa fa-pen'
    }) }}
</ul>

…et c'est terminé !

Vous pouvez commencer à personnaliser le CRUD en modifiant ExampleAdminController et sa methode getConfiguration. La documentation est ici.