PROJET AUTOBLOG


Planet-Libre

source: Planet-Libre

⇐ retour index

Admin-Linux : Phabricator – open source, software engineering platform

jeudi 2 octobre 2014 à 14:37

Phabricator est une collection d’applications web open source qui aident les éditeurs de logiciels à construire de meilleurs logiciels.

Phabricator semble être un outils complet pour la gestion de cycle de vie d’application.

Voici une liste de ses fonctionnalités :

Revue de code

Permet de passez en revue le code des autres avec Differential :

  • Afficher le code de manière lisible
  • Il est possible de rejeter le code si il ne convient pas
  • Revue de code pré-push plutôt que post-push
  • Moins de risque d’erreur avec cette méthode
  • Vous pouvez voir un exemple de code ici : D212

differential

Héberge des repositories Git/Mercurial/SVN Repositories, ou se connecte avec d’autres hôtes

Phabricator peut héberger Git, Mercurial et Subversion. Il est également possible de se connecter avec des repositories existant (comme GitHub, Bitbucket, ou d’autres dépôts que vous ont déjà ailleurs)

 

Gestion de projet

Avec Projects il est possible de gérer des projets et ses tâches associées
projects

Travail en équipe

Phabricator a été crée pour favoriser le travail en équipe :
  • Fournit des salons de discussion instantanée (chat) avec Conpherence
  • Fournit des flux d’activité
  • Vous pouvez tenir un wiki avec Phriction

conpherence

 

phriction

 

Parcourir et Auditer le code source

Utilisation de Diffusion pour parcourir le code source dans votre navigateur.

diffusion

 

Suivi de bugs

Suivi de bugs et problème Have terrible software? Gardez une trace de tous les bugs et problèmes sur votre code à l’aide Maniphest

  • Suivi de bugs
  • Possibilité d’assigner un bug à quelqu’un
  • Peut-être que vous pourriez les corriger par la suite. (facultatif)
  • Par exemple, regardez cette faille dans Phabricator même: T2000

maniphest

 

Se prémunir de certains danger

Il est possible de garder une trace des l’activités, mais surtout d’en être informé avec Herald

  • Écrire des règles de gestion
  • Être notifié en cas de modification de certains fichiers

 

herald

CLI

Arcanist est un outils en ligne de commande qui vous fournit un accès CLI aux majeures fonctionnalités de Phabricator

  • Beaucoup de commandes
  • Les couleurs ANSI sont supportées
  • Fonctionne sous Linux, Mac OS X et Windows.

arcanist

API

L’API Conduit API vous permet d’écrire des scripts qui interagisse avec Phabricator au travers d’une API HTTP JSON

 

Alors vous en pensez quoi ? Ça donne envie non ? Et bien regarder la Roadmap, ça vous donnera encore plus envie ;)

 

Voici les fonctionnalités en approche :

Kanban / Workboards

Désormais disponible en Beta

workboards

ACLs / Policies

Désormais disponible dans beaucoup d’applications

acl

Design Review

Désormais disponible en Beta

  • Comme la revue de code, mais pour les images

pholio_mini

Support for Mobile/Devices

Désormais disponible dans beaucoup d’applications

Ça fonctionne sur beaucoup d’application, mais pas encore toutes :

  • Review code — sur un petit écran !
  • Manage bugs — en utilisant vos doigts pour effectivement les toucher !
  • Browse source — de n’importe où dans le monde civilisé !

maniphest_mobile

 

J’ai découvert cette solution hier, et elle me semble vraiment très pro et vraiment prometteuse, reste à voir dans la vie réelle, mais elle mérite d’être essayée.

 

Liens utiles :

Site officiel de Phabricator

Phabricator sur le projet Phabricator

L'article Phabricator – open source, software engineering platform est apparu en premier sur L'admin sous GNU / Linux - Blog Libre.

Gravatar de Admin-Linux
Original post of Admin-Linux.Votez pour ce billet sur Planet Libre.

Sheldon.fr : La livebox et son loopback … « Go fuck ! »

jeudi 2 octobre 2014 à 12:16
Illustration issue de Degroupnews.com

Illustration issue de Degroupnews.com

Je suis très content de mon FAI (Sosh), qui m’offre de très bons débits (78/16) pour un prix modique et en « paysannie » !
Mais ils ont une livebox  Play comme modem/routeur :(

Elle est lente, moche, pleines de bugs, manque un tas d’options, et cale très mal les meubles.
donc elle est bonne à rien !

Mon plus gros reproche, est l’absence d’option pour gérer le loopback !
Comme vous le savez, je m’auto-héberge, ce qui veut dire que de chez moi, je suis susceptible d’accéder à des ressources via un nom de domaine  qui pointe en local.
la plus part des box opérateurs gèrent ça très bien, sauf bien sur, la livebox !
de l’extérieur sheldon.fr pointe sur mon serveur, de chez moi ça redirige vers … l’interface d’administration de la livebox :/

 

Quelles alternatives s’offrent à moi ?

Il en reste une dernière, monter son propre DNS local avec les usines habituelles telles que Bind, Bind9 …
ou alors maître en place Dnsmasq !

dnsmasqhttp://www.thekelleys.org.uk/dnsmasq/doc.html

Dnsmasq, c’est quoi ?

c’est un petit outil tout mignon, tout léger, qui fait des tas de trucs  et qui est très simple à administrer, pas mal non ?
On peut en faire :

On essai ?

J’ai décidé de monter un container pour gérer ce service, et bien évidemment j’utilise encore et toujours … OpenVZ (on va pas se refaire hein !)
mais une fois n’est pas coutume, il y a quelques modifs à faire sur le CT à savoir :

vzctl set CTID --capability setuid:on --save
vzctl set CTID --capability net_admin:on --save
vzctl set CTID --capability net_raw:on --save

Pour le reste des caractéristiques, j’ai mis : 1 core, 256 Mo ram, et 4 Go de disque
et je suis large, une fois ma VM configurée et Dnsmasq installé, elle consomme 9 Mo ram, et 8 taches (ça doit être ma plus petite VM ^^) !

l’installation n’est pas trop compliquée :

apt-get install dnsmasq

la partie configuration se situe dans /etc/dnsmasq.conf
voici un exemple de ma config et ses commentaires.

# utilisation du nom de domaine complet pour les requetes DNS
domain-needed

#simule les requetes reverses en local
bogus-priv

#interface d'écoute
interface=eth0

#mon domaine
domain=sheldon.fr

#la taille du cache en nombres de requetes
cache-size=1000

# Cette directive permet d'ajouter le domaine défini ci-dessous aux noms simples figurant dans /etc/hosts
expand-hosts

#gestion des logs, attention c'est verbeux !
log-facility=/var/log/dnsmasq.log
log-queries


# plage dynamique de 192.168.0.110 à 192.168.0.149 avec un bail de 24h
dhcp-range=192.168.0.110,192.168.0.149,255.255.255.0,24h

#les options se déclare avec type,valeur - ici la valeur 3 est la passerelle de ma livebox
dhcp-option=3,192.168.0.1

# adresse IP fixe pour la machine FF:FF:FF:FF:FF:FF
#dhcp-host=FF:FF:FF:FF:FF:FF,test,192.168.0.15

# Désactiver cette directive uniquement si votre serveur est le serveur DHCP officiel du réseau
dhcp-authoritative


#déclaration pour mon serveur xmpp
address=/xmpp.sheldon.fr/192.168.0.241
srv-host=_xmpp-client._tcp.sheldon.fr,192.168.0.241,5222
srv-host=_xmpp-server._tcp.sheldon.fr,192.168.0.241,5269
txt-record=_xmppconnect.sheldon.fr,"_xmpp-client-xbosh=http://sheldon.fr:5280/http-bind"

 

Le fichier resolv.conf

#mon domaine
domain sheldon.fr
search sheldon.fr

#la déclaration DNS
#en premier il s’interroge lui même afin de vérifier si il a la requête en cache
nameserver 127.0.0.1
#si il ne la connaît pas, il interroge un autre DNS
nameserver 208.67.222.222

 

La déclaration des machines en local, dans /etc/hosts :
mon fichier avec quelques exemples :

fe00::0         ip6-localnet
00::0           ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters



192.168.0.220   zimbra  zimbra.sheldon.fr
192.168.0.239   munin   munin.sheldon.fr
192.168.0.241   xmpp    xmpp.sheldon.fr
#...

127.0.0.1 localhost
192.168.0.10 ovz-dns.sheldon.fr  ovz-dns

::1             localhost ip6-localhost ip6-loopback

 

n’oubliez pas un /etc/init.d/dnsmasq restart après les modifications !

 

Dnsmasq est très pratique, il permet également la déclaration pour le protocole XMPP :)
Autre limitation de la livebox (décidément …), je ne peux pas modifier les DNS transmis par son propre serveur DHCP, j’ai donc été obligé de le désactiver (mince alors) pour utiliser celui de dnsmasq, afin qu’il renseigne sa propre ip en tant que DNS au client DHCP.
La partie cache, fonctionne également très bien, exemple :

Première requête, elle n’est pas dans le cache, elle est donc transmise vers mon DNS qui fait autorité (temps : 26ms)

dig linux.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37505
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;linux.org.			IN	A

;; ANSWER SECTION:
linux.org.		3104	IN	A	107.170.40.56

;; Query time: 26 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct  2 11:34:54 2014
;; MSG SIZE  rcvd: 43

à la seconde requête, elle est cette fois dans le cache, le traitement est instantané :

dig linux.org

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> linux.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24005
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;linux.org.			IN	A

;; ANSWER SECTION:
linux.org.		3103	IN	A	107.170.40.56

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct  2 11:34:55 2014
;; MSG SIZE  rcvd: 43

Vous souhaitez vérifier le bon fonctionnement ?
allons faire un tour dans les logs :

Oct  2 11:34:54 dnsmasq[3027]: query[A] linux.org from 127.0.0.1
Oct  2 11:34:54 dnsmasq[3027]: forwarded linux.org to 208.67.222.222
Oct  2 11:34:54 dnsmasq[3027]: reply linux.org is 107.170.40.56
Oct  2 11:34:55 dnsmasq[3027]: query[A] linux.org from 127.0.0.1
Oct  2 11:34:55 dnsmasq[3027]: cached linux.org is 107.170.40.56
Oct  2 11:40:18 dnsmasq[3027]: query[A] linux.org from 127.0.0.1
Oct  2 11:40:18 dnsmasq[3027]: cached linux.org is 107.170.40.56

On voit donc la première requête est adressé à 208.67.222.222, qui la résous, puis la mets en cache, lors du second appel, c’est le cache de Dnsmasq qui répond.

Autre exemple, lorsque je veux utiliser ma webmail depuis chez moi, avant je tombais sur l’interface de la livebox, maintenant dnsmasq voit l’enregistrement présent dans /etc/hots et corrige ma requête DNS :

Oct  2 11:59:23 dnsmasq[3027]: query[A] zimbra.sheldon.fr from 192.168.0.211
Oct  2 11:59:23 dnsmasq[3027]: /etc/hosts zimbra.sheldon.fr is 192.168.0.220

Conclusion :
c’est simple à mettre en place (à peine 5/10 min), facile à maintenir, très souple (bon faut chercher un peu dans les options) et libre !
que demander de plus ?

Gravatar de Sheldon.fr
Original post of Sheldon.fr.Votez pour ce billet sur Planet Libre.

Articles similaires

Tuxicoman : Linux sucks

jeudi 2 octobre 2014 à 09:03

Une présentation rigolote sur Linux. La manière dont la deuxième partie prend le contrepoint de la première est une belle figure de style pour une présentation « Powerpoint »

J'aime(1)Ferme-la !(0)

Related Posts:

Gravatar de Tuxicoman
Original post of Tuxicoman.Votez pour ce billet sur Planet Libre.

Olivier Delort : Le changement c’est pour bientôt

jeudi 2 octobre 2014 à 08:00

A travers ce titre racoleur, je dois l’avouer, il s’agit plutôt d’une conjecture sur mon envie de changement concernant ma solution d’auto-hébergement plutôt qu’un sujet politique. Depuis 2011 je suis sur la même plate-forme, plusieurs machines virtuelles hébergées sur proxmox qui lui-même est installé sur un ordinateur de salon classique. Après un premier bilan il y a deux ans j’étais satisfait de cette solution, elle me convenait très bien. Mais le problème c’est que j’aime le changement, la remise en question, la nouveauté et les nouveaux défis.

Mon premier serveur(droite) sous mandrake 10

Mon premier serveur(droite) sous mandrake 10, lors de nos lan

Les gamers

Les Gamers

Les Gamers

Les Gamers

A l’époque j’avais concrétisé pas mal d’année de travail et de recherche en réalisant ce projet qui me tenait à coeur, m’auto-héberger presque en totalité. Ce projet à commencer au début de mes études en informatiques et il ne m’a jamais quitté depuis. Pourquoi confier à d’autres mes courriels, données, création, alors que j’ai la compétence pour le faire ? L’idée ne m’est pas venu un beau matin en me levant. Tout a commencé pendant mon BTS lorsque j’hébergeais pour tous les gamer de ma classe un petit forum et les versions serveurs de nos jeux préférés (counter-strike, quake 3, ennemi territory et bien d’autre), cela nous permettait de nous fragger (comme on dit le jargon gamer) après une dure journée de chauffage de banc. La seule constante avec aujourd’hui c’est que tous mes serveurs tournent sous Linux que j’ai découvert en 1995 avec une Mandrake 5.3. Depuis j’ai amélioré mes compétences, mes connaissances, ma technicité, sur l’administration système, réseau. Par la suite ce fut mon métier et j’ai commencé par héberger :

De ce point de départ beaucoup de choses ont évoluées, certains serveurs ont disparu d’autre ont vu le jour suite à des besoins spécifiques (gitlab, owncloud, piwik, …). Aujourd’hui les choses continuent encore d’évoluer, Proxmox me correspond de moins en moins, le matériel vieillit (3 ans de fonctionnement 24/24 7/7), la quantité de données croit exponentiellement chaque année. Pour faire une parenthèse sur Proxmox je ne leur reproche absolument rien en particulier, mais il se tourne de plus en plus vers les entreprises leur cible principale et je les comprends. Proxmox m’a rendu pas mal de services en tant que particulier, mais n’étant pas une entreprise et ne souhaitant pas le devenir, je commence à chercher d’autre solution de virtualisations. Cela n’enlève rien à la qualité du logiciel, bien au contraire je suis sûr qu’il en sera encore meilleur.

Mon matériel aussi à évoluer au fil des ans, au départ il y avait :

Premier Pare-feu, Jetway mini-ITX sous ipcop

Pare-feu,  mini-ITX sous ipcop

first-firewall1

La bête mes à nue

Depuis le NAS et le pare-feu ont été virtualisés, mais avec le temps je m’aperçois que tous regroupé n’est pas forcément une bonne chose non plus, il faut trouver le juste milieu. Je repartirai très certainement sur trois appareils comme au départ, d’ailleurs j’ai déjà commencé avec le pare-feu : une Carte Alix avec ipfire.

Maintenant je souhaite passer sur une installation plus silencieuse, moins énergivore et moins encombrante niveau matériel. Toujours basée sur la virtualisation qui est pour moi une technologie d’avenir. Concrètement j’établis un pseudo mon cahier des charges.

Le matériel

Comme expliquer plus haut le cas du pare-feu est réglé, le plus facile. Il ne me reste plus que le futur serveur et le Nas. Tous deux doivent répondre aux mêmes contraintes :

J’avoue que je louche de plus en plus sur les cartes de type bay trail, j’ai d’excellent retours de la part de plusieurs amis qui utilisent ses cartes-mères.

Deux modèles se détachent, le premier c’est la gigabyte GA-C1037UN-EU, la seconde c’est la MSI J1800I.

La gigabyte est plus adaptée en utilisation serveur, deux cartes réseau, 3 ports sata, possibilité d’ajouter de la RAM jusqu’à 16 go sur slot standard ce qui me permetra de garder la RAM de mon précédent serveur.

Je verrai plus la MSI en tant que Nas, seulement une carte réseau, des slots mémoires pour portable, Ram maxi 8Go.

En comptant le boîtier, l’alimentation, la Ram pour la MSI, je suis pratiquement dans mon budget.

En sachant que récupère tous Disque durs, certains sont tous neufs, la RAM, tout ce qui est petit câblage (Sata, alim etc …)

Le Logiciel

Comme je l’expliquais plus haut proxmox ne répond plus à mes besoins. Il me faut une solution de virtualisation moins gourmande en ressources que KVM, moins obsolète que OpenVZ (en ce qui concerne sur Debian). Et puis j’ai envi de décourvrir d’autre logiciel de virtualisation. Et plus précisément Docker, on peut parler de conteneur plus que de virtualisation pure.

J’ai donc commencé mes investigations sur Docker et je compte bien en apprendre plus. Du côté des hôtes virtualisés cela ne bougera pas trop, très certainement je basculerai tous mes serveurs web sous nginx, j’en ai marre de gérer la doublette avec apache, qui malgré mes optimisations il devient de plus en plus gourmand.

Rien n’est arrêté, je commence à peine mes réflexions sur mon nouveau projet, s’il le faut la semaine prochaine je partirai sur une autre installation. Mais ce qui est sûr c’est que je vais commencé à travailler sur Docker puis le matériel viendra tout seul.

Cela promet de belles aventures, que je ne manquerai pas de partager ici.

Gravatar de Olivier Delort
Original post of Olivier Delort.Votez pour ce billet sur Planet Libre.

Articles similaires

Wooster by CheckmyWebsite : Check liste pour passer un site de HTTP à HTTPS

jeudi 2 octobre 2014 à 08:00

Vous le savez déjà ou vous allez l’apprendre maintenant, Google a annoncé au mois d’août sa décision de favoriser dans les résultats de recherche les sites utilisant le protocole HTTPS en lieu et place de HTTP. La problématique du passage de HTTP à HTTPS va donc se poser pour mal de webmasters désireux de conserver un « ranking optimal ».

Voici une petite check-list des diverses choses à entreprendre pour un passage en douceur de votre site en HTTPS. C’est la procédure que j’ai suivi pour l’ensemble des sites de la galaxie Check my Website qui sont désormais tous opérés avec le plus haut niveau de sécurité SSL histoire de préparer la commercialisation du service qui ne saurait tarder désormais.

1 : Choisir et acheter un certificat SSl

Il n’est pas question dans le contexte présent d’utiliser un certificat auto-signé, Google n’apprécierait que moyennement, pour ne pas dire plus !

Choisir un certificat SSL n’est pas toujours une sinécure. Il en existe de plusieurs types et les dénominations commerciales des uns et des autres rendent les comparaisons entre ceux-ci assez difficiles.

Les prix profitent de la confusion des genres bien sûr puisque ils vont du simple à plus du triple pour le même type de certificats et de garantie.

En fonction du niveau de confiance dont vous avez besoin, optez au choix pour un certificat SSL simple ou au contraire comme nous l’avons fait pour un certificat avec « Extended Validation ». C’est celui qui permet l’affichage de la fameuse barre verte à côté du traditionnel cadenans dans le navigateur.

La procédure d’obtention de ce type de certificat est plus contraignante puisque vous devez validez la structure opérant le site web à protéger et pas seulement le domaine.

2 : Configurer le serveur web pour utiliser SSL/TLS

Il y a pléthore de tutoriaux bien faits pour installer un certificat SSL sur Nginx ou Apache. N’ayant rien de plus à apporter, je me contenterais donc de vous renvoyer vers ces deux-ci :

2.1 : SPDY, En attendant HTTP/2

Cerise sur le gâteau et en attendant HTTP/2 qui intégrera le protocole en standard, vous pouvez activer SPDY sur votre couche SSL histoire d’améliorer les performances de votre nouveau site en HTTPS.

Pour Nginx

Après avoir vérifié qu evotre installation de Nginx supporte SPDY, ce qui est le cas sur mon Ubuntu avec la version des dépôts, remplacez simplement la déclaration habituelle de la directive listen

listen 10.10.10.10:443 ssl;

en

listen 10.1.2.3:443 ssl spdy;

Pour Apache

Comme toujours avec Apache, il faut charger le module mod_spdy et compléter la configuration comme suit pour chaque hôte virtuel :

SpdyEnabled on

Vous pouvez vérifier la prise en compte de SPDY pour votre serveur avec ce service en ligne. Voilà par exemple le rapport pour la console Check my Website.

3 : Rediriger tout le trafic vers HTTPS

Le but est bien sûr de mettre en place une redirection 301 « redirection permanente » pour l’ensemble des pages présentes sur le site.

Que ce soit pour Nginx ou Apache, la manipulation est très simple et ne demande que quelques minutes.

Pour Nginx

Un bloc de ce type par domaine à rediriger et puis c’est tout.

server {
  listen 80;
  server_name _;
  return 301 https://$host$request_uri;
}

Pour Apache

Un bloc comme celui du dessous devrait pouvoir faire l’affaire ; à condition d’avoir activé le module mod_rewrite.

RewriteEngine On
RewriteCond %{HTTPS} off
Redirect permanent / https://www.domain.tld/

4 : Mettre à jour les Google Webmaster Tools

La première idée qui vient est de changer l’adresse des sites déjà existants dans les GWT par la nouvelle adresse commençant par https://. Que nenni ! Cela aurait été trop simple et la procédure à suivre est un peu plus contraignante puisqu’il faut déclarer le site en HTTPS comme un nouveau site.

Et si vous avez des liaisions avec des comptes analytics, elles sont aussi à redéclarer. Un peu lourd mais bon !

5 : mettre à jour les liens

Alors là, c’est carrément le morceau fastidieux de l’affaire et le travail à faire dépend grandement du type d’outil de publication que vous utilisez.

N’hésitez pas à vous aider de l’un des vérificateurs de liens dont nous avons déjà parlé. Ils détectent les redirections et permettent donc ce genre de travail.

N’oubliez pas les liens comme les appels aux librairies et feuilles de style externes qui doivent désormais se faire en HTTPS sous peine de warning.

Ainsi un appel vers les Google Fonts qui était auparavant en

  • http://fonts.googleapis.com/css?family=Roboto:400,300,300italic,400italic,700,700italic|Bree+Serif:400 devient
  • https://fonts.googleapis.com/css?family=Roboto:400,300,300italic,400italic,700,700italic|Bree+Serif:400 ou mieux
  • //fonts.googleapis.com/css?family=Roboto:400,300,300italic,400italic,700,700italic|Bree+Serif:400 qui permet de continuer à utiliser le protocole demandé pour la page.

6 : Mettre à jour votre supervision

Comme vous êtes un webmaster soucieux de la qualité de votre site web « sinon pourquoi vouloir passer en HTTPS ? » ; vous supervisez votre site web avec un ou plusieurs outils de supervision. N’oubliez donc pas de les mettre à jour même si une redirection est en place.

Et puis, maintenant, il vous faut en plus monitorer la date de fin de validité de votre certificat SSL sous peine d’avoir quelques soucis de connexion à la date d’anniversaire du renouvellement.

Ce type de contrôle devrait bientôt faire parti des outils offerts par le service Check my Website.

6.1 : Mise à jour des sites dans la console Check my Website

Le service Check my Website accepte depuis toujours de contrôler indifféremment les sites en HTTP et HTTPS.

Du coup, la seule chose à faire est de vous rendre dans les préférences du ou des sites web à changer et de cliquer sur l’url dans le panneau Général. Remplacez simplement HTTP par HTTPS et basta !!!

Ouf c’est fini… Enjoy !

Rien de bien compliqué donc pour passer son site de HTTP à HTTPS mais quand même un ensemble de petites choses à penser qui font que la procédure demande pas mal de temps. En espérant que ce petit pense-bête vous aidera à ne rien oublier et si jamais vous voyez un manquement, les commentaires sont là pour compléter.

Gravatar de Wooster by CheckmyWebsite
Original post of Wooster by CheckmyWebsite.Votez pour ce billet sur Planet Libre.