WikiBR - Contributions [fr]

Hébergement des sites des binets

2013-09-18T20:47:03Z

Xavier.bonnetain : PHP 5.4 & 200Mo par défaut

{{menu services}}

Le BR propose aux binets qui le désirent d'héberger gratuitement leur site web.

Cet hébergement s'organise selon deux formules, avec ou sans la possibilité d'accéder au site de l'extérieur du Plâtal.

Pour demander l'hébergement de ton site, envoie un mail à root@eleves.polytechnique.fr.

== Sans visibilité extérieure ==

Les sites internes sont hébergés sur [[Admin:Kevarzh | Kevarzh]].

L'administration du site se fait par accès ftp en écriture, ouvert à tous les administrateurs Frankiz du binet considéré, ce qui nécessite d'identifier chaque site hébergé sur Kevarzh à un unique groupe Frankiz.

L'écriture du site est bien entendu à la charge du webmaster du binet ; en cas de nécessité et pour une raison valable, un BRman pourra cependant proposer son aide.

L'adresse du site est alors mon_binet.binets.fr ou mon_binet.binets.eleves.polytechnique.fr, ou plus simplement mon_binet.bin ;

Voir par exemple le site de la Diskhâle Classique : [http://dhc.binets.fr http://dhc.binets.fr] ou [http://dhc.binets.eleves.polytechnique.fr http://dhc.binets.eleves.polytechnique.fr] ou [http://dhc.bin http://dhc.bin].

Pour accéder aux fichiers, il faut utiliser un client FTP (comme [http://filezilla-project.org/ FilleZilla Client]) et accéder au serveur [ftp://binets ftp://binets]. Le serveur FTP demande un login/mot de passe qui correspondent exactement aux comptes Frankiz. Le dossier ftp://binets/www/UN_BINET/htdocs/ correspond au site http://UN_BINET.binets.fr/. Les fichiers qui ne sont pas dans htdocs ne sont pas accessible directement par un navigateur, mais un script PHP peut y accéder.

La base de données MySQL est accessible par un PhpMyAdmin : [http://phpmyadmin.bin/ http://phpmyadmin.bin/] (ou .binets, mais pas .binets.fr). Le nom d'utilisateur correspond au nom du binet tel qu'il apparaît dans le nom de domaine. Le mot de passe est défini par le BR et est généralement généré avec une méthode similaire à [http://www.random.org/passwords/ Random.org].

== Avec visibilité extérieure ==

Le BR s'est équipé d'un VPS (serveur privé virtuel à l'extérieur du Plâtal) permettant d'héberger des sites binets avec visibilité extérieure indépendamment des autorités de l’École. L'adresse de tels sites a pour suffixe binets.fr, comme [http://br.binets.fr/ br.binets.fr] ou [http://faerix.binets.fr/ faerix.binets.fr] par exemple.

Les sites souhaitant un site avec visibilité depuis l'extérieur doivent dorénavant respecter la charte suivante :

*Aucune information ne doit être diffusée qui pourrait nuire à l'image de l’École. (photos, vidéos, etc.)
*Le site doit avoir une qualité visuelle, si ce n'est professionnelle, du moins très correcte.
*Le site ne doit pas héberger de vidéos ou diffuser un flux vidéo (streaming). Toutes les vidéos du sites doivent être hébergées à l'extérieur. (Dalymotion, YouTube, etc.)
*Les images présentes sur le site ne doivent avoir une résolution suffisamment faible afin de ne pas saturer la bande passante vers l'extérieur.

*Le BR offre ce service gratuitement, en partie grâce à une subvention de la Kès. Il se réserve le droit de refuser ou d'interrompre l'hébergement d'un site, sans préavis, sans recours possible et sans avoir à fournir de motif. Il s'engage à en informer immédiatement le bureau du binet concerné.

== Modalités techniques ==
L'hébergement offert par le BR présente les caractéristiques suivantes :
* Capacité de stockage limitée à 200Mo par défaut. Il est possible d'obtenir plus sur demande.
* Serveur apache avec PHP 5.4
* Base de données MySQL
* Possibilité d'accès en HTTPS pour votre site en option.

Si vous avez des besoins plus spécifiques, n'hésitez pas à nous en parler.

[[Catégorie:Services]]

Git

2013-02-24T22:20:04Z

Xavier.bonnetain : git:// est utilisable à travers kuzh

{{menu Root Toolbox}}

Git est un [[VCS|système de contrôle de version]]. Assez proche de [[SVN]] par certains côtés, il présente néanmoins un grand nombre de différences.

Avant de découvrir les spécificités de Git, il est nécessaire de connaître les concepts généraux des [[VCS|systèmes de contrôle de version]].

Cette page donne un bref aperçu des fonctionnalités de Git. Un autre bon aperçu est disponible [http://giudoku.sourceforge.net/media/GitHandbook.pdf ici] (lien non BR)

Une cheatsheet est également disponible [http://ndpsoftware.com/git-cheatsheet.html ici], c'est un bon aide mémoire.

== Dépôts ==

Alors que [[CVS]] et [[SVN]] sont des systèmes de versionnement centralisés (i.e un serveur contient le dépôt, et chaque utilisateur effectue un ''checkout'' depuis ce dépôt), Git est complètement décentralisé. Cela signifie que chaque contributeur a sa propre copie locale de tout l'historique d'un projet. Si aujourd'hui vous considérez que l'espace disque sur votre ordinateur est un problème, allez faire un tour, partez admirer les merveilles de la technologies qui nous entoure, et revenez demain. Sur cette page, tous les examples sont tirés du Git de [[Frankiz]], mais voici d'autres dépôts bien utiles :
* [http://www.github.com/ GitHub]
* [http://git.frankiz.net/ Frankiz]
* [http://git.polytechnique.org/ Polytechnique.org]

== Récupérer le code d'un projet existant ==

Pour télécharger un projet existant, il y a deux possibilités : avec un compte de développeur ou sans compte. Avec un compte SSH simple, il suffit d'exécuter la commande suivante :
git clone mybeautifulname@git.frankiz.net:/hosting/git/frankiz
Sans compte, certains projets sont téléchargeables avec le protocole HTTP, mais vous ne pourrez pas uploader vos modifications.
git clone http://git.frankiz.net/frankiz

Cela crée un '''clone''' du dépôt d'origine (i.e une copie conforme), qui peut d'ailleurs servir de backup si le dépôt d'origine était perdu. Notre clone contient tout l'historique du dépôt depuis sa création, toutes les branches, etc. Cette première opération est très souple. On peut cloner des dépôt via SSH, HTTP, GIT, ou même en local le dépôt d'un autre utilisateur...

Par exemple la commande suivante clone dans le dossier ''platal'' la branche ''core/master'' d'une version de Plat/al potientiellement modifiée par le vice-prez 2010 :
git clone /home/2010/fishilico/dev/platal/.git platal -b core/master

== Accéder à l'aide ==
Avant toute chose, il est essentiel de savoir où trouver de l'aide, d'autant plus que l'aide de Git est très bien faite.
* Sur internet, il y a le wikiBR, les pages de manuel ([http://linux.die.net/man/1/git sur Linux Die] par exemple) et le [http://book.git-scm.com/ Git Book]
* En terminal, ''git help'' pour une liste des commandes, ''git help cmd'' ou ''git cmd --help'' pour l'aide complète de la commande ''cmd'', ou encore simplement ''git cmd -h'' pour une aide courte sur la commande ''cmd''

== Quel est l'état de ma copie de travail ? ==
Ceci est la question que vous devez vous posez avant de reprendre après une pause votre travail sur un projet versionné. Il peut y avoir eu des changements sur le projet entre temps, des patchs mal faits en production, ... Pour cela, il y a trois commandes essentielles :
* Pour vérifier que le dépôt est correct, ''git status'' doit dire cela :
git status
# On branch master
nothing to commit (working directory clean)
* En cours de travail, la réponse ressemble plus à :
git status
# On branch master
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: un-fichier-random.blah
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# un-fichier-chombier-ajouté.42
no changes added to commit (use "git add" and/or "git commit -a")
* Lire l'historique est bien pour savoir quel est le dernier commit
git log
commit 2a424aae1e746fb5f33de3b3bc3e8a31ee25c684
Author: Nicolas Iooss <fishilico@eleves.polytechnique.fr>
Date: Fri Mar 9 00:27:35 2012 +0100
* Voir les différences entre la version sur le dépôt distant et celle de travail
git diff

De plus, après avoir téléchargé les derniers commits avec ''git fetch'', il est possible d'obtenir le message suivant :
git status
# On branch master
# Your branch is behind 'origin/master' by 42 commits, and can be fast-forwarded.
Cela signifie que la copie locale a 42 commits de retard sur le dépôt distant, mais qu'un ''git rebase origin/master'' suffit pour mettre à jour la copie locale.

== Réinitialiser le dépôt ==
Pour restaurer un fichier, il suffit de le ''checkout'' à partir de l'index. En français, cela signifie que lorsque vous faites une modification sur un fichier, vous pouvez effacer les modifications et revenir la dernière version enregistrée dans l'index Git avec la commande :
git checkout -- chemin/vers/mon/fichier.blih
Pour réinitialiser l'index dans l'état indiqué par une branche (comme ''master'' par exemple) sans modifier les fichier, il suffit d'écrire :
git reset master
Si cela ne marche pas car des fichiers seront modifiés ou effacés, on peut forcer la main à Git, mais alors il faut être prêt à subir les conséqences que cela implique (perte des modifications non commitées)
git reset --hard master

== Mettre à jour la copie de travail ==
=== git fetch && git rebase origin/master ===
Dans le cas général, vous travaillez sur la branche ''master'' et vous synchronisez votre projet sur un seul serveur. Si votre cas est plus compliqué, vous devez être suffisamment compétent pour vous débrouillez par vous-même. On disait donc... dans le cas simple, Git stocke en interne deux branches : ''master'' et ''origin/master''. Sur Frankiz, c'est un peu plus compliqué car il y a une branche de production, mais les développeurs n'utilisent que master.
git branch -a
* master
remotes/origin/HEAD -> origin/master
remotes/origin/f579e1971a66623b2948bf0e20c2e23481022b41
remotes/origin/fkz2
remotes/origin/kangz-h4ck3s
remotes/origin/master
remotes/origin/prod

Pour mettre à jour sa copie de travail, il faut donc commencer par mettre à jour les branches distantes, avec '''au choix''' l'une des commandes suivantes
git fetch
git fetch origin

Ensuite, il faut appliquer les éventuelles modifications locales à la suite de celles effectuées sur le dépôt, c'est le '''rebase'''.
git rebase origin/master
Git essaiera alors d'appliquer les commits locaux successivement, en indiquant chaque fois qu'il y a un problème (conflit ou fichier supprimé). En cas de problème, il faut
# Résoudre le problème (les fichiers avec des conflits apparaîssent comme ''Changed but not updated'' dans ''git status'')
# Ajouter les fichiers (''git add'')
# Indiquer à git de continuer : ''git rebase --continue''

Remarque : git pull --rebase est un raccourci pour l'ensemble git fetch && git rebase. Attention cependant lors du travail sur plusieurs branches.

Ceci permet de transformer l'état suivant (les ''O'' sont les commits, ''A'' le moment où les deux versions ont commencé à diverger, ''B'' la version du dépôt, ''E'' la version locale, ''C'' et ''D'' des commits locaux

-C--D--E
/
-O--A--O--B

En l'état plus propre :
-O--A--O--B--C'--D'--E'

Avec C, D et E convertis en C', D' et E' : ils ont été modifiés pour être des modifications relatives à B au lieu de A.

=== Pourquoi il ne faut JAMAIS utiliser git pull ===
Certains développeurs utilisent la commande ''git pull'' pour mettre à jour leur dépôt. Cette pratique est justifiée lorsque la copie de travail était propre (sans commit en attente de push entre autres), mais sinon, cela peut avoir des conséquences très graves et sales. En effet, ''git pull' est assimilé à la succession de commandes suivantes :
git fetch origin && git merge origin/master
Le problème est le merge. En reprenant les schémas précédents, cela transforme l'état suivant :

-C--D--E
/
-O--A--O--B

en :

-C--D--E
/ \
-O--A--O--B----M

où M est le commit ''de fusion de branches''. '''Cela est très moche et à éviter absolument'''. Si vous vous retrouvez dans cette suituation (pour vérifier : ''git log''), vous pouvez toujours tenter un ''git rebase origin/master'' qui peut fonctionner si le ''merge'' était trivial (sans conflit). Sinon, un ''git reset --hard origin/master'' s'impose pour assurer votre salut.

=== Sauvegarder des modifications locales (git stash) ===
Avant de faire un merge particulièrement délicat, ou si l'on doit résoudre un bug alors que l'on a pas mal de modifications non commitées en cours, il est parfois utile de sauvegarder l'état courant de la copie de travail.

Pour cela, il faut utiliser '''avant''' un changement (avec ''git rebase'' par exemple) :
git stash
Une fois les modifications effectuées, on peut restorer la copie locale à l'état sauvegardé avec :
git stash pop

== Effectuer un commit ==
Un '''commit''' est un ensemble de fichiers modifiés. Cela permet plus de cohérence dans le suivi des versions. Par exemple, si l'ajout d'une fonctionnalité sur Frankiz modifie les fichiers ''blah'', ''blih'' et ''bloh'', le ''commit'' regroupe les modifications de ces trois fichiers, et associe à cette modification une date et un auteur.

Pour effectuer un commit, il faut :
* Vérifier l'état de la copie de travail, pour ne commiter que ce qui est nécessaire
git status
git diff
* Indiquer à Git quels fichiers feront partie du commit ; ceci permet de ne committer que les modifications de quelques fichiers
git add path/to/blih path/to/blah path/to/bloh
* Vérifier que l'on a ajouté les fichiers que l'on voulait :
git status
* Faire le commit (le ''-s'' ajoute une ligne ''Signed of by'' dans le message, pour pouvoir retrouver plus efficacement l'auteur réel du commit)
git commit -s
* Cette commande ouvre un éditeur (vi, nano ou emacs selon la configuration de la variable EDITOR). Il faut alors entrer un bref descriptif du commit. '''Pour certains projets (dont Frankiz), les conventions de codage obligent les développeurs à écrire les descriptions en anglais.''' Il est un bon usage de s'adapter en conséquence, car un commit peut être refusé en production s'il est mal fait.
* Mettre à jour la copie locale avec le dépôt distant (cela décale le nouveau commit à la fin). '''IL NE FAUT SURTOUT PAS FAIRE DE git pull OU DE git merge ICI'''
git fetch
git rebase origin/master
* Transmettre les commits au dépôt d'origine
git push

La dernière commande provient du fait que git n'est pas centralisé : il n'envoie pas les modifications locales au dépôt parent spontanément.

Ceci permet de faire quelques modifications locales puis de n'envoyer cela au reste des développeurs que lorsque les modifications sont stables et complètes, par exemple.

== Gérer les branches ==
On peut voir la liste des branches accessibles avec :
git branch -a
* La ligne avec une étoile est la branche courante
* Les lignes blanches sont les branches ''locales'' (elles suivent généralement une branche distante)
* Les lignes rouges (si les couleurs sont activées) sont les branches distantes.

Pour récupérer une autre branche, il faut d'abord l'ajouter localement :
git checkout -b NomLocal origin/NomDistant

Cela aura également pour effet de basculer sur la branche NomLocal.
Les modifications que l'on avait effectuées sont bien entendu conservées.

Une fois la branche ajoutée, on peut basculer de branche en branche à l'aide de :
git checkout NomLocal

== Créer un dépôt ==
Contrairement à [[SVN]] où il faut installer un serveur subversion, créer un dépôt Git est très rapide : dans le dossier que l'on souhaite versionner, il suffit de taper
git init
Et voilà, le dossier est versionné : on peut donc commencer à faire des modifications, des commits, etc. (bien entendu, on ne peut pas ''pusher'' ses commits, puisqu'il n'y a pas de serveur distant).

Cette particularité rend Git très efficace pour versionner un petit projet, un exercice de TD, etc.

Pour créer un dépôt qui peut être cloné, il faut exécuter les commandes suivantes :
git init --bare mon_projet
cd mon_projet && git update-server-info

Enfin, pour configurer un serveur HTTP (gitweb), il ne faut pas oublier de créer un fichier vide '''git-daemon-export-ok''' dans le dossier, afin de permettre le clonage.

== Structure interne ==

Git stocke les commits de manière très particulière : un commit correspond à peu près à une sauvegarde de l'état des fichiers, à un message, et à une référence vers le commit parent.
Contrairemant à [[SVN]], il n'y a donc pas de notion de numéro de révision : chaque commit est identifié par une chaîne hexadécimale de 40 caractères (par exemple : ''04fd02e59b1bdc430c7a7dcc1ca9f4cbc2b04037'' )

Un ''tag'' est en fait un nom «lisible» donné à un ''commit'' ; une ''branche'' indique également le ''commit'' principal d'une branche.

== Du bon usage de gitignore ==
Dans un projet, il est inutile de versionner les fichiers temporaires et les fichiers compilés (qu'ils soient binaires ou non). On utilise généralement un Makefile pour créer ces fichiers. Pour éviter de les versionner, il suffit d'utiliser un fichier ''.gitignore'' bien placé. Généralement, chaque projet a un tel fichier dans son dossier principal. Voici par exemple un extrait du gitignore de Frankiz :
configs/frankiz.conf
htdocs/.htaccess
htdocs/data/*
htdocs/css/*
spool/*
upgrade/2.0.0_to_3.0.0/unversionned

== Configuration globale ==
Si vous avez déjà commitez, vous aurez certainement remarqué qu'il faut utiliser ''git config'' pour configurer vos informations personnelles. Ainsi, les deux premières commandes que tout utilisateur doit taper avant de faire un commit sont :
git config --global user.name "Prénom Nom de famille"
git config --global user.email "prenom.nom.promo@polytechnique.org"

Ensuite, si vous aimez les couleurs, vous avez envie de taper cette commande :
git config --global color.ui auto

Enfin, si vous en avez assez des projets qui ne mettent pas les fichiers temporaires dans le gitignore, vous pouvez configurer un fichier gitignore global. Si votre ''/home/user/.gitignore_global'' ressemble à
*~
*.swp
*.tmp
il suffit de taper :
git config --global core.excludesfile /home/user/.gitignore_global

Tout cela permet de gérer la configuration globale, visible par
git config --global -l
En enlevant ''--global'' dans toutes les commandes précédentes, on configure la copie locale.

=== Exemple de configuration ===
Voici un exemple de fichier ~/.gitconfig (qui stocke la configuration ''--global'', le même format peut être utilisé dans les fichier ''$REPO/.git/config'' de chaque dépot) :
[gc]
auto = 1
[color]
ui = true
[color "diff"]
whitespace = red reverse
[core]
whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff --cached
lg = log -p
lo = log --graph --decorate --pretty=oneline --abbrev-commit -n 10
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
ls = ls-files
# Show files ignored by git:
ign = ls-files -o -i --exclude-standard
amend = commit --amend -C HEAD
[branch]
autosetuprebase = always

== Utiliser le proxy de l'X avec Git ==
Si vous hébergez un projet sur [http://www.github.com GitHub], vous avez envie de dire à Git de se connecter à GitHub en SSH en passant par le proxy de l'X (qui est [http://kuzh.polytechnique.fr:8080 kuzh:8080]). Pour cela, il suffit de configurer le client SSH pour utiliser le proxy à chaque connexion vers github.com. Cela s'effecute par le fichier de configuration suivant dans /home/user/.ssh/config (adaptez avec votre dossier personnel)
Host github.com
ProxyCommand socat - PROXY:kuzh.polytechnique.fr:%h:%p,proxyport=8080

Si vous souhaitez utiliser le protocole git://, il faut utiliser socat, et créer un exécutable avec dedans :
#!/bin/sh
exec socat STDIO PROXY:129.104.247.2:$1:$2

Puis mettre cet executable dans la variable core.gitproxy :
git config --global core.gitproxy NOM_DU_FICHIER

N'oubliez pas d'enlever cette variable pour utiliser git en-dehors de l'X.

'''Si vous souhaitez uniquement cloner un dépôt GitHub''' dont vous n'êtes pas contributeur, il suffit d'utiliser le lien HTTPS en ligne de commande, en précisant le proxy.
export https_proxy=http://kuzh.polytechnique.fr:8080
git clone https://github.com/BinetReseau/frankiz.git

Finalement, si vous ne voulez pas vous connecter par ssh, mais vous souhaitez travailler normalement avec un depôt à l'extérieur de l'X, configurez git par le biais de ces commandes:
git config --global http.proxy http://kuzh.polytechnique.fr:8080
git config --global https.proxy http://kuzh.polytechnique.fr:8080

Cela va effectuer les modifications correspondantes sur le fichier ~/.gitconfig. '''N'oubliez pas de les enlever dès que vous n'êtes plus connectés au réseau de l'école, avec''':
git config --global --unset http.proxy http://kuzh.polytechnique.fr:8080

= Pour Windows =

Pour utiliser Git sur Windows, on peut par exemple télécharger MSys Git : [http://msysgit.github.com/ http://msysgit.github.com/].

[[Catégorie:Root]]

Modèle:Content serveurs

2013-02-03T13:34:25Z

Xavier.bonnetain :

'''Général :'''
{| style="background-color:transparent"
|
* [[Admin:Serveurs_du_BR|Les serveurs]]
|
* [[Admin:Configuration des serveurs|Configuration]]
* [[Réseau:Attribution des prises local BR|Réseau du local]]
|}

'''Détails :'''
{| style="background-color:transparent"
|
* [[Admin:Frankiz|Frankiz]]
* [[Admin:Heol|Heol]]
* [[Admin:Deiz|Deiz]]
* [[Admin:Kevarzh|Kevarzh]]
* [[Admin:Moaz|Moaz]]
* [[Admin:Envorenn|Envorenn]]
|
* [[Admin:Lodan|Lodan]]
* [[Admin:Lunedenn|Lunedenn]]
* [[Admin:Galloudel|Galloudel]]
* [[Admin:Skignerezh|Skignerezh]]
* [[Admin:Koun|Koun]]
* [[Admin:Onduleur|Onduleurs]]
|}
'''Anciens serveurs'''
{| style="background-color:transparent"
|
* [[Admin:Gwennoz|Gwennoz]]
* [[Admin:Pellwel|Pellwel]]
|
* [[Admin:Skinwel|Skinwel]]
* [[Admin:Enez|Enez]]
|}

Modèle:Réunions2011

2013-01-16T23:50:59Z

Xavier.bonnetain :

* [[Réunion:2012-12-19_Magnan_BR-ENSTA|Magnan-BR du 19 décembre 2012, avec l'ENSTA]]
* [[Réunion:2012-12-20_Kes-BR| Réunion avec la Kès du 20 décembre 2012]]
* [[Réunion:2013-01-16_1ere|1ère Réunion BR 2011 du 16 janvier 2013]]

Modèle:Réunions2011

2013-01-16T23:50:47Z

Xavier.bonnetain :

* [[Réunion:2012-12-20_Kes-BR| Réunion avec la Kès du 20 décembre 2012]]
* [[Réunion:2012-12-19_Magnan_BR-ENSTA|Magnan-BR du 19 décembre 2012, avec l'ENSTA]]
* [[Réunion:2013-01-16_1ere|1ère Réunion BR 2011 du 16 janvier 2013]]

BR2011

2013-01-16T23:48:36Z

Xavier.bonnetain :

{{menu BR}}

===== Membres du BR 2011 =====
{| border=0 align=center
| ||| Victor BERGER (levans) ||| ''' prez | root | dev '''
|-
| ||| Xavier BONNETAIN (havelock) ||| ''' vprez | root | dev | fkz4 '''
|-
| ||| Théo COMBE (thunder) ||| ''' trez | dev | root '''
|-
| ||| Michel BLANCARD (gerard) ||| ''' screz | dev | root '''
|-
| ||| Olivier GAUTHÉ (arcos) ||| ''' web '''
|-
| ||| Chantal DING (talchan) ||| ''' web '''
|-
| ||| Jean-Mathieu TEISSIER (gnogno) ||| ''' web '''
|-
| ||| Jean-Matthieu GALLARD (JM) ||| ''' web '''
|-
| ||| Robin Larrieu (gaunt) ||| ''' dev '''
|-
| ||| François ESPINET (netix) ||| ''' dev '''
|-
| ||| Gabriel GOUVINE (alnurn) ||| ''' dev '''
|-
| ||| Hoang-Chuong TRAN (thchuong) ||| ''' '''
|-
| ||| Jean-Matthieu GALLARD ||| ''' dev '''
|-
| ||| Olivier GAUTHÉ (arcos) ||| ''' '''
|-
| ||| Chantal DING (talchan) ||| ''' '''
|-
| ||| Zelda MARIET (triforce) ||| ''' dev '''
|-
| ||| Pierre-Alexandre Murena (pam) ||| ''' dev '''
|-
| ||| Arturo RUANO SAN MARTIN ||| ''' '''
|-
| ||| Thomas FERREIRA DE LIMA (tedima) ||| ''' dev '''
|-
| ||| Omar EL EUCH (omareuch) ||| ''' '''
|-
| ||| Carlo FERRARI (carlal) ||| ''' '''
|-
| ||| Arthur JUNG ||| ''' '''
|-
| ||| Cheick Mohady SISSIKO (wcicheick) ||| ''' '''
|-
| ||| Yi REN (bci) ||| ''' '''
|-
| ||| Guillaume LAMPLE (guismay) ||| ''' '''
|-
| ||| Neeraj BAPAT (fisher ||| ''' '''
|-
| ||| Titouan RIGOUDY (titz) ||| ''' '''
|}

Modèle:Content Root Toolbox

2013-01-10T23:43:10Z

Xavier.bonnetain :

{|
|
* [[Admin:Mise_à_jour|Mise à jour]]
* [[BR:Overlay|Overlay BR]]
* [[Admin:UID|UID root]]
* [[Admin:Subversion|Subversion]]
* [[Git|Git]]
* [[Admin:SVN_Root|SVN Root]]
* [[Admin:Cron|Cron]]
* [[Admin:NTP|NTP]]
* [[Admin:Kvm|Kvm]]
|
* [[Admin:Framebuffer|Framebuffer]]
* [[Admin:Postfix|Postfix]]
* [[Admin:Apache|Apache]]
* [[Admin:DNS|Bind]] / [[Admin:Dns_App|Dns App]]
* [[Admin:LDAP|LDAP]]
* [[Admin:Monitoring|Monitoring]]
* [[Admin:Onduleur|Onduleur]]
* [[Admin:CertificatsSSL|Certificats SSL]]
* [[Admin:Trac|Trac]]
|
* [[Admin:Yubikeys|Yubikeys]]
* [[Admin:Espace disque|Espace disque]]
* [[Admin:Espace disque#Logrotate|Logrotate]]
* [[Admin:Backups|Sauvegardes]]
* [[Admin:Quota|Quota]]
* [[Admin:Raid|Raid]]
* [[Admin:Logical volume|Logical volume]]
* [[Admin:Swap|Swap]]
|}

Modèle:Réunions2011

2012-12-20T07:31:29Z

Xavier.bonnetain : Réunion Kès

* [[Réunion:2012-12-19_Magnan_BR-ENSTA|Magnan-BR du 19 décembre 2012, avec l'ENSTA]]
* [[Réunion:2012-12-20_Kes-BR| Kès-BR du 20 décembre 2012]]

Modèle:Content support téléphone 2k12

2012-12-13T17:14:34Z

Xavier.bonnetain :

* Victor "Levans" Berger (prez)
78 31
* Xavier "Havelock" Bonnetain (vprez)
78 93
* Théo "Thunder" Combe (root)
78 37
* Gabriel "Alnurn" Gouvine (root)
78 82

En dernier recours, tu peux aussi essayer de [[Modèle:Content_support_téléphone_2k10|contacter un BRman 2010]].

Modèle:Content support téléphone

2012-12-13T17:14:01Z

Xavier.bonnetain : MaJ post-passation

* Pour les entreprises qui veulent contacter des élèves mais qui ne veulent pas spécialement entrer en contact avec le binet réseau, il est préférable de contacter la Kès des élèves par mail à kes@eleves.polytechnique.fr ou par téléphone
06 88 71 29 98
06 72 00 54 53

* Les numéros de téléphone à jour sont sur [https://www.frankiz.net/groups/see/br Frankiz]

{{Content_support_téléphone_2k11}}