Modifications entre les versions 3 et 66 (s'étendant sur 63 versions)
Version 3 à la date du 2009-02-24 20:43:54
Taille: 3057
Éditeur: MoussaNombre
Commentaire: ça se précise
Version 66 à la date du 2015-11-21 13:25:25
Taille: 14006
Éditeur: MoussaNombre
Commentaire: jour3
Texte supprimé. Texte ajouté.
Ligne 1: Ligne 1:
#acl GroupeAUF:read,write #acl GroupeAUF:read,write All:read
Ligne 3: Ligne 3:
= Mission : Installation du système informatique du nouveau bâtiment de l'Ifgcar = <<TableOfContents>>

= Mission : 17 au 28 novembre 2015 à Port-au-Prince =
Ligne 7: Ligne 9:
 * Aller (départ de Montréal) : mardi 17 mars 2009
 * Retour (départ de Port-au-Prince) : mardi 24 mars 2009
||<<MonthCalendar(,2015,11,,,1)>> ||
Ligne 10: Ligne 11:
##== Plan de vols ==  * Départ de Montréal : mardi 17 novembre à 9h30 -- arrivée PaP à 13h50 (Air Canada vol 1814)
 * Départ de Port-au-Prince : samedi 28 novembre à 16h15 (American AirLine vol 201) -- Miami 18h26-20h04 (AA, vol 1465)-- arrivée Montréal à 23h38
Ligne 12: Ligne 14:
== Objectif principal ==
 Mettre en place le coeur du système informatique du nouveau bâtiment : réseau, Internet, parefeu, messagerie, sauvegarde, authentification.
Ligne 15: Ligne 15:
__NB__ : '''prendre les dispositions pour travailler samedi et dimanche''' == Objectifs principaux ==

 * restructuration de l’infrastructure technique (réduction/optimisation du nombre de serveurs, mutualisation de certains services vers le central)
  * on passera de 4 à 2 serveurs (voire 1 serveur)
  * le service de partage de fichiers se fera via nuage.auf.org
  * mise en place d'un dispositif d'accès distant
 * analyse/résolution des difficultés/soucis techniques récurrents
 * entretiens de recrutement d'un technicien
 
'''NB''' :
 1. il faudra prévoir de '''travailler les samedi et dimanche''' de la mission afin de procéder à la mise en production de la nouvelle infrastructure (arrêts et redémarrages des serveurs) sans perturber les collègues et les abonnés.
 1. '''informer les abonnés des changements à venir''' (ils n'auront plus d'espace de stockage sur les machines) et les mesures d'accompagnement (à préciser et mettre en place)
 1. prévoir la '''fermeture du CNF le Jour 1 à partir de 14h''' (une heure plus tôt que d'habitude) : modification à apporter aux postes et au serveur.

__Les sauvegardes__ :
 1. Il n'y aura aucune sauvegarde des postes public (CNF), cf NB 2 ci-dessus
 1. Les postes du personnel seront sauvegardés vers un espace disque sur super-bc via '''[[http://doc.ubuntu-fr.org/deja-dup|Déjà-Dup]]''' (installé par défaut sur nos postes).
    . Ce qui donne, au passage, une grande autonomie au personnel sur leurs données et les besoins restaurations en cas de nécessité.
    . Du coup, on n'a plus besoin du serveur de sauvegarde
    . [Faire une sauvegarde des clés de chiffrement]
 1. La sauvegarde des serveurs se fera vers Montréal (OVH) durant la nuit (aucun impact pour les utilisateurs le jour)

== Travaux préliminaires ==
 * Par LBM :
  * configuré et tester Déjà-Dup sur son poste

 * Par NM (à Montréal) :
  * procéder aux achats de matériel
  * [[ZC/CNFPaP/SuperBC|serveur]] :
   * installer Debian Jessie (firmeware-nonfree) + Libvirt/qemu + config de la VM gw.ht.auf (cf photo plus bas) sur les nouveaux disques achetés
   * transfert de la VM pfsense
   * conversion/transfert du CT voip
  * configuration du [[ZC/CNFPaP/KVMIP|kvm-ip et du pcu]]
 * préparation suppression du NFS
  * postes du personnel (migration des partages dans nuage.auf.org)
   * [LBM] installer client owncloud 2.0 sur les postes du personnel
    . cocher option confirmation pour le téléchargement de dossier/fichier de plus de [10Mo ?]
   * [NM/LBM] transférer dans nuage.auf.org les dossiers partagés (coordonner avec PatrickHétu)
    . [PatrickHétu] création du partage '''[[AUF-partage-BC]]''' avec un admin principal et des sous dossiers (droits à gérer par l'admin)
   * [LBM] désactiver autofs (exit 0 dans /etc/default/autofs)
   * [LBM] au passage, check list :
    * TB : activation de la synchro imap et des contacts
    * home : chiffré ?
  * postes du CNF
   * NM : valider procédure de bascule
    * fonctionnement avec des comptes type "invité" : profil dans /home/tmp/[username], shell particulier (cf compte guest d'Ubuntu)
    * création des homedir : activer pam-mkhomedir
    * nettoyage des homedir : cron de nettoyage des tmp : ajouter /home/tmp/*, [garder 7jours ???]
    * /home/tmp : partition séparée si possible ou activer quota disque (pour ne pas que les usagers bousillent toute la partition /)
    * vérifier le miroir
    * vérifier/maj configs preseed local



== Planning et compte-rendu ==

||'''Quand'''||'''Quoi'''||'''Qui'''||'''Compte-rendu au jour le jour'''||
||<|2> Jour 1 : mercredi 18||<(> [Matinée] : <<BR>> * Réunion avec la Direction : <<BR>> ** peaufiner les derniers détails du planning de la mission <<BR>> ** point sur les ressources techniques du Bureau (notamment la connexion Internet, le projet de déménagement et le personnel informatique) <<BR>> * Réunion technique avec LBM avant le début des travaux||NM/LBM/Direction||<(> * NB : ce jour est férié en Haïti. Nous avons donc travaillé juste une demie-journée <<BR>> * La réunion avec la Direction est reportée à jeudi||
||<(> [Après-midi] ''NB :'' '''Il faudra fermer le CNF à compter de 14h''' <<BR>> * modification des postes du CNF (désactivation de NFS, pam-mkhomedir, nettoyage tmp, quota ou partion séparée, etc) <<BR>> * modification des comptes a-d-u : HOMEDIR=/home/tmp/`username` <<BR>> * transfert des disques du serveur auth-nfs sur le serveur new-vz-bc (Attention : rm de udev/70-net) : auth-nfs devient '''super-bc''' <<BR>> * remise en service du serveur auth-nfs (en fait new-vz-bc qui contient les disques du auths-nfs) (service d'authentification pour le CNF et dossiers partagés du personnel)||NM/LBM||<(> * NFS désactivé sur les postes <<BR>> ** on garde le /home/username <<BR>> ** exit 0 dans /etc/default/autofs <<BR>> ** suppression du lien /home <<BR>> ** mkdir /home <<BR>> ** activer pam_mkhomedir (modif dans /etc/pam.d/common_session) <<BR>> ** nettoyage du /home à chaque démarrage des postes (rm -rf /home* dans /etc/rc.local) <<BR>> * Pas touché aux serveurs; le [[ZC/CNFPaP/SuperBC|nouveau serveur]] acheté à Montréal sera finalisé pour la prod.||
||<|5> Jour 2 : jeudi 19||<(> [Matinée] <<BR>> * installation des "disk-from-Mtl" dans super-bc <<BR>> * installation de super-bc (installation dans le rack, connexion réseau, configuration switch vlan)||NM||<(> * '''Arrivée au bureau : 8h45''' <<BR>> * Rien n'a été installé dans le rack vu que les anciens serveurs y sont encore. On fera tout ça le week-end (sortir les anciens et mettre les nouveaux). <<BR>> * les disques ont été installés dans le serveur. Mais, grosse surprise : encore une carte RAID physique impossible de désactiver ! Finalement, en raid0, ça marche, on arrive à booter sur les disques. <<BR>> * J'ai passé énormément de temps à vouloir intégrer le super-bc et la vm passerelle dans le réseau actuel avec de "vraies" IP sans cassé la prod actuelle. <<BR>> * On s'y attendait : il y a un soucis avec les bridges : rien ne sort n'y entre ! ... '''A REVOIR''' <<BR>> * La vm de base pour voip est prête, reste à installer Asterisk 1.8 et migrer la config <<BR>> * Réunion avec la Direction : point sur la présélections des candidats pour le poste de tech bureautique, procédures de sélection (entretien avec questions générales et techniques, pas de test écrit), présentation des éléments clés (changements à venir) de la mission, point sur les démarches en cours pour l’acquisition de la liaison Internet Digicel et l'augmentation du débit de Natcom||
||* installation du KVM-IP et du PCU (installation dans le rack et connexion aux serveurs||LBM||Reporté au week-end ||
||<(> [Après-midi] <<BR>> * configuration du KVM-IP et du PCU||NM||Juste changé l'IP du KVM. Le PCU n'est pas encore installé, sera fait le week-end. ||
||<(> * installation du client owncloud 2.0 sur les postes du personnel (activer le filtre de limitation de téléchargement selon la taille) <<BR>> * configuration de Déjà-Dup sur les postes du personnel <<BR>> * désactiver l'accès NFS||LBM||<(> * Config owncloud : OK <<BR>> * Config DéjàDup : commencée ... '''À FINALISER''' ||
||[Fin de journée - 15h] * lancer le transfert des données des partages NFS dans nuage.auf.org||LBM||<(> * Déjà fait par NM depuis Montréal <<BR>> * '''Départ du bureau : 15h30 !!!''' (suite à l'hôtel sur une connexion Internet qui marche tant bien que mal ... quel calvaire !!!)||
||<|4> Jour 3 : vendredi 20||<(> * suite de la configuration des services parefeu, de la gestion des 2 liens Internet et de l'accès au RPV AUF||NM||Plutôt attardé sur la résolution des soucis de bridges. Heureusement la grosse expérience de ProgFou a permis de débloquer la situation rapidement (cf les [[ZC/Missions/2015/Novembre/FeuilleDeRoute#A.2BAMk-changes_avec_JC_sur_les_soucis_de_bridges|échanges]] plus bas) <<BR>> * (soir à l'hôtel) cette histoire de raid matériel risque de nous causer des soucis : j'ai remarqué que les disques sont vus finalement comme des /dev/mdabc (genre (/dev/md123 pour sda). Je n'ai pas réussi à mettre en place mon raid logiciel sur la 2ème paire de disques ... '''A REVOIR'''||
|| * finalisation de la VM pfsense (reconfiguration des interfaces réseaux)||LBM||Fait par NM ||
|| * finalisation et mise en service de la Voip||LBM||Début de la conversion du CT asterisk18 en vm voip ... '''A FINALISER''' ||
|| * configuration des sauvegardes hors site (Duplicity) des serveurs||LBM||Reste le cas des VM (comment faire ???) ||
||<|1> Jour 4 - samedi 21||<(|2> * on récupère (offline) un des disques du RAID de super-bc pour le mettre sur super-bc-secours <<BR>> * mise en production de la nouvelle infrastructure <<BR>> * test de la bascule d'un lien Internet à l'autre||<(|2> NM/LBM || ||
||<|1> Jour 5 - dimanche 22|| ||
||<|1> Jour 6||<(> * gestion des éventuels soucis découlant des changements effectués <<BR>> * assistance générale : <<BR>> ** impossibilité d'utiliser nos lignes téléphoniques fixes pour appeler l'international <<BR>> ** la connexion des ordinateurs à un réseau wifi empêche de profiter simultanément de la connexion internet et de l'accès aux fichiers (je sais, ça semble bizarre mais Beethoven sait de quoi je parle...) <<BR>> ** Divers||NM/LBM|| ||
||<|2> Jour 7||* suite assistance <<BR>> * finalisation du serveur secours||NM|| ||
||* retrait et mise au rencart des serveurs inutilisés (old vz-bc, backup, boukman)||LBM|| ||
||<|2> Jour 8|| * mise à jour de la documentation globale (mise à jour du wiki) <<BR>> * rédaction d'une procédure de bascule en cas de panne du serveur principal||NM|| ||
||* réunion de synthèse avec la Direction||NM/LBM/Direction|| ||
||<|1> Jour 9||<(|2> Entretiens et tests de recrutement d'un technicien||<(|2> NM/LBM/JPM||<|2> ||
||<|1> Jour 10||
||<|1> Jour 11||départ pour Montréal ||NM|| ||

|| Réinstallation des postes clients en Trusty||

== Schémas de l'infrastructure ==
||{{attachment:schemas-it-bc.png|schémas avant et après|width=400}}||{{attachment:infra3.0.png|Infra Tech 3.0|width=400}}||

== Besoin en matériel ==
 * KVM-IP
 * PCU
 * Disques durs : 4 x 1TB
 * Barrettes mémoires (pour auth-nfs et new-vz-bc)

== Annexes ==

=== Échanges avec JC sur les soucis de bridges ===
{{{
(13:01:51) moussa.nombre@auf.org/3277039268144837733412656: je suis embourbé dans cette histoire d'interfaces/ponts
(13:02:39) moussa.nombre@auf.org/3277039268144837733412656: hier nuit, finalement tout était bien, mes interfaces de passerelle fonctionnaient
(13:02:54) moussa.nombre@auf.org/3277039268144837733412656: j'y avait accès depuis le lan
(13:03:24) moussa.nombre@auf.org/3277039268144837733412656: et là ce matin, j'arrive au bureau, il y a eu panne de courant, tout a rebooté, et pouf plus rien ne marche
(13:03:28) moussa.nombre@auf.org/3277039268144837733412656: bizarre
(13:04:42) Progfou : ok
(13:04:46) moussa.nombre@auf.org/3277039268144837733412656: dès que tu as 1 minute ...
(13:04:51) Progfou : donc je dirais : forwarding
(13:05:03) Progfou : filtrages sur les bridges
(13:05:08) Progfou : rp_filter
(13:05:11) Progfou : choses de ce genre

(13:06:29) moussa.nombre@auf.org/3277039268144837733412656:
root@super-bc:~# cat /etc/sysctl.d/local.conf
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.ipv6.conf.all.disable_ipv6 = 1
root@super-bc:~#
(13:11:17) Progfou : vérifies que c'est effectivement actif
(13:11:44) Progfou : car j'avais eu des soucis avec le sysctl -p qui n'appliquait pas mes config' dans /etc/sysctl.d/ (qui est pourtant la bonne place)
(13:12:13) Progfou : (vérifier = grep . /proc/sys/net/bridge/bridge-nf-call-*)
(13:12:46) moussa.nombre@auf.org/3277039268144837733412656: ah ha !
(13:12:53) moussa.nombre@auf.org/3277039268144837733412656:
root@super-bc:~# sysctl -a | grep bridge
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-filter-pppoe-tagged = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-pass-vlan-input-dev = 0

root@super-bc:~# grep . /proc/sys/net/bridge/bridge-nf-call-*
/proc/sys/net/bridge/bridge-nf-call-arptables:1
/proc/sys/net/bridge/bridge-nf-call-ip6tables:1
/proc/sys/net/bridge/bridge-nf-call-iptables:1

(13:13:19) Progfou : ok
(13:13:53) moussa.nombre@auf.org/3277039268144837733412656: faut les déplacer dans le sysctl.conf alors ?
(
(13:14:37) Progfou : oui, mets les dans le principal en attendant de comprendre pourquoi ça se fait pas en dessous

(13:14:52) Progfou : ou sinon mets des appels sysctl dans ton script firewall
(13:15:09) Progfou : ce sera peut-être plus robuste en cas d'upgrade

(13:15:32) moussa.nombre@auf.org/3277039268144837733412656: aurais-tu un exemple pour moi
(
(13:16:06) Progfou : sysctl -w net.bridge.bridge-nf-call-arptables=1

(13:16:36) Progfou : sysctl -w net/bridge/bridge-nf-call-arptables=1
(13:17:01) Progfou : l'intérêt c'est que tu peux copier-coller depuis un chemin parcouru dans le shell (en retirant juste le préfixe /proc/sys/)

(13:21:30) moussa.nombre@auf.org/3277039268144837733412656: comme d'hab : tu es un génie :)
(13:21:48) moussa.nombre@auf.org/3277039268144837733412656: ça marche tout de suite :)
(13:21:52) moussa.nombre@auf.org/3277039268144837733412656: ouf ouf ouf
}}}
Ligne 18: Ligne 167:

== Travaux préliminaires ==
 * vérification et déballage du matériel
 * déplacement d'un des serveurs NFS au CNF
 * installation de base de Lenny sur tous les serveurs
 * finalisation et test du câblage réseau
 * installation de NFS : CNF et IFGCAR
 * configuration des routeurs wifi (à transformer en portail captif par la suite). Configurer certains en pont wifi
 * mise en place du serveur de sauvegarde avec backuppc

----

== CNF de PaP ==

=== Jour 1 -- CNF -- mercredi ===

==== Matinée ====
 * rencontre avec les Responsables (Directeur/Administrateur/CNF)
 * séance de travail avec Beetho pour cadrer le programme
 
==== Après-midi ====
 * vérification de la configuration du serveur NFS et migration du système d'authentification sur ce serveur
 * préparation de la mise en production : test NFS + authentification centralisée

----

== IFGCAR ==
=== Jour 2 - jeudi ===
 * finalisation de l'architecture (on se met d'accord avant de commencer le travail)
 * installation du rack
 * configuration des switchs VLAN
 * installations des switchs
 * configuration du parefeu

=== Jour 3 - vendredi ===
 * configuration du partage de charge sur les deux connexions Internet
 * mise en fonction du réseau

=== Jour 4 - samedi ===
 * virtualisation du serveur central
 * configuration du DNS et de la messagerie ht.auf.org et ifgcar.auf.org ; ce qui inclut modification de la configuration au niveau du CNF (qui gère actuellement ces services)

=== Jour 5 - dimanche ===
 * mise en place du backup hors site du CNF
 * configuration du switch VLAN et mise en place
 * mise en production partielle (sur quelques postes) de l'authentification centralisée + NFS
 
=== Jour 6 - lundi ===
 * suivi des nouvelles configurations et corrections des éventuels bugs
 * mise en place du serveur web. Les sites à migrer le seront plus tard depuis le serveur du CNF.

=== Jour 7 - mardi ===
 * points sur les travaux
 * zou ... aéroport, direction Montréal

----

== Restera à faire ==
 * migration du site de l'IFGCAR
 * configuration authentification centralisée et NFS à l'IFGCAR
 * mise en production de l'authentification centralisée + NFS à l'IFGCAR (configuration des postes clients)
 * étude de la migration Ubuntu des postes étudiants avec virtualbox pour les travaux sous MS Windows
 * installation de proxy SQUID à l'IFGCAR et finaliser celui du CNF
 * finalisation du déploiement de l'authentification centralisée + NFS au CNF

Mission : 17 au 28 novembre 2015 à Port-au-Prince

Dates

<< <  2015 / 11 >  >>
Lun Mar Mer Jeu Ven Sam Dim
            1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30            
  • Départ de Montréal : mardi 17 novembre à 9h30 -- arrivée PaP à 13h50 (Air Canada vol 1814)
  • Départ de Port-au-Prince : samedi 28 novembre à 16h15 (American AirLine vol 201) -- Miami 18h26-20h04 (AA, vol 1465)-- arrivée Montréal à 23h38

Objectifs principaux

  • restructuration de l’infrastructure technique (réduction/optimisation du nombre de serveurs, mutualisation de certains services vers le central)
    • on passera de 4 à 2 serveurs (voire 1 serveur)
    • le service de partage de fichiers se fera via nuage.auf.org
    • mise en place d'un dispositif d'accès distant
  • analyse/résolution des difficultés/soucis techniques récurrents
  • entretiens de recrutement d'un technicien

NB :

  1. il faudra prévoir de travailler les samedi et dimanche de la mission afin de procéder à la mise en production de la nouvelle infrastructure (arrêts et redémarrages des serveurs) sans perturber les collègues et les abonnés.

  2. informer les abonnés des changements à venir (ils n'auront plus d'espace de stockage sur les machines) et les mesures d'accompagnement (à préciser et mettre en place)

  3. prévoir la fermeture du CNF le Jour 1 à partir de 14h (une heure plus tôt que d'habitude) : modification à apporter aux postes et au serveur.

Les sauvegardes :

  1. Il n'y aura aucune sauvegarde des postes public (CNF), cf NB 2 ci-dessus
  2. Les postes du personnel seront sauvegardés vers un espace disque sur super-bc via Déjà-Dup (installé par défaut sur nos postes).

    • Ce qui donne, au passage, une grande autonomie au personnel sur leurs données et les besoins restaurations en cas de nécessité.
    • Du coup, on n'a plus besoin du serveur de sauvegarde
    • [Faire une sauvegarde des clés de chiffrement]
  3. La sauvegarde des serveurs se fera vers Montréal (OVH) durant la nuit (aucun impact pour les utilisateurs le jour)

Travaux préliminaires

  • Par LBM :
    • configuré et tester Déjà-Dup sur son poste
  • Par NM (à Montréal) :
    • procéder aux achats de matériel
    • serveur :

      • installer Debian Jessie (firmeware-nonfree) + Libvirt/qemu + config de la VM gw.ht.auf (cf photo plus bas) sur les nouveaux disques achetés
      • transfert de la VM pfsense
      • conversion/transfert du CT voip
    • configuration du kvm-ip et du pcu

  • préparation suppression du NFS
    • postes du personnel (migration des partages dans nuage.auf.org)
      • [LBM] installer client owncloud 2.0 sur les postes du personnel
        • cocher option confirmation pour le téléchargement de dossier/fichier de plus de [10Mo ?]
      • [NM/LBM] transférer dans nuage.auf.org les dossiers partagés (coordonner avec PatrickHétu)

      • [LBM] désactiver autofs (exit 0 dans /etc/default/autofs)
      • [LBM] au passage, check list :
        • TB : activation de la synchro imap et des contacts
        • home : chiffré ?
    • postes du CNF
      • NM : valider procédure de bascule
        • fonctionnement avec des comptes type "invité" : profil dans /home/tmp/[username], shell particulier (cf compte guest d'Ubuntu)
        • création des homedir : activer pam-mkhomedir
        • nettoyage des homedir : cron de nettoyage des tmp : ajouter /home/tmp/*, [garder 7jours ???]
        • /home/tmp : partition séparée si possible ou activer quota disque (pour ne pas que les usagers bousillent toute la partition /)
        • vérifier le miroir
        • vérifier/maj configs preseed local

Planning et compte-rendu

Quand

Quoi

Qui

Compte-rendu au jour le jour

Jour 1 : mercredi 18

[Matinée] :
* Réunion avec la Direction :
** peaufiner les derniers détails du planning de la mission
** point sur les ressources techniques du Bureau (notamment la connexion Internet, le projet de déménagement et le personnel informatique)
* Réunion technique avec LBM avant le début des travaux

NM/LBM/Direction

* NB : ce jour est férié en Haïti. Nous avons donc travaillé juste une demie-journée
* La réunion avec la Direction est reportée à jeudi

[Après-midi] NB : Il faudra fermer le CNF à compter de 14h
* modification des postes du CNF (désactivation de NFS, pam-mkhomedir, nettoyage tmp, quota ou partion séparée, etc)
* modification des comptes a-d-u : HOMEDIR=/home/tmp/username
* transfert des disques du serveur auth-nfs sur le serveur new-vz-bc (Attention : rm de udev/70-net) : auth-nfs devient super-bc
* remise en service du serveur auth-nfs (en fait new-vz-bc qui contient les disques du auths-nfs) (service d'authentification pour le CNF et dossiers partagés du personnel)

NM/LBM

* NFS désactivé sur les postes
** on garde le /home/username
** exit 0 dans /etc/default/autofs
** suppression du lien /home
** mkdir /home
** activer pam_mkhomedir (modif dans /etc/pam.d/common_session)
** nettoyage du /home à chaque démarrage des postes (rm -rf /home* dans /etc/rc.local)
* Pas touché aux serveurs; le nouveau serveur acheté à Montréal sera finalisé pour la prod.

Jour 2 : jeudi 19

[Matinée]
* installation des "disk-from-Mtl" dans super-bc
* installation de super-bc (installation dans le rack, connexion réseau, configuration switch vlan)

NM

* Arrivée au bureau : 8h45
* Rien n'a été installé dans le rack vu que les anciens serveurs y sont encore. On fera tout ça le week-end (sortir les anciens et mettre les nouveaux).
* les disques ont été installés dans le serveur. Mais, grosse surprise : encore une carte RAID physique impossible de désactiver ! Finalement, en raid0, ça marche, on arrive à booter sur les disques.
* J'ai passé énormément de temps à vouloir intégrer le super-bc et la vm passerelle dans le réseau actuel avec de "vraies" IP sans cassé la prod actuelle.
* On s'y attendait : il y a un soucis avec les bridges : rien ne sort n'y entre ! ... A REVOIR
* La vm de base pour voip est prête, reste à installer Asterisk 1.8 et migrer la config
* Réunion avec la Direction : point sur la présélections des candidats pour le poste de tech bureautique, procédures de sélection (entretien avec questions générales et techniques, pas de test écrit), présentation des éléments clés (changements à venir) de la mission, point sur les démarches en cours pour l’acquisition de la liaison Internet Digicel et l'augmentation du débit de Natcom

* installation du KVM-IP et du PCU (installation dans le rack et connexion aux serveurs

LBM

Reporté au week-end

[Après-midi]
* configuration du KVM-IP et du PCU

NM

Juste changé l'IP du KVM. Le PCU n'est pas encore installé, sera fait le week-end.

* installation du client owncloud 2.0 sur les postes du personnel (activer le filtre de limitation de téléchargement selon la taille)
* configuration de Déjà-Dup sur les postes du personnel
* désactiver l'accès NFS

LBM

* Config owncloud : OK
* Config DéjàDup : commencée ... À FINALISER

[Fin de journée - 15h] * lancer le transfert des données des partages NFS dans nuage.auf.org

LBM

* Déjà fait par NM depuis Montréal
* Départ du bureau : 15h30 !!! (suite à l'hôtel sur une connexion Internet qui marche tant bien que mal ... quel calvaire !!!)

Jour 3 : vendredi 20

* suite de la configuration des services parefeu, de la gestion des 2 liens Internet et de l'accès au RPV AUF

NM

Plutôt attardé sur la résolution des soucis de bridges. Heureusement la grosse expérience de ProgFou a permis de débloquer la situation rapidement (cf les échanges plus bas)
* (soir à l'hôtel) cette histoire de raid matériel risque de nous causer des soucis : j'ai remarqué que les disques sont vus finalement comme des /dev/mdabc (genre (/dev/md123 pour sda). Je n'ai pas réussi à mettre en place mon raid logiciel sur la 2ème paire de disques ... A REVOIR

* finalisation de la VM pfsense (reconfiguration des interfaces réseaux)

LBM

Fait par NM

* finalisation et mise en service de la Voip

LBM

Début de la conversion du CT asterisk18 en vm voip ... A FINALISER

* configuration des sauvegardes hors site (Duplicity) des serveurs

LBM

Reste le cas des VM (comment faire ???)

Jour 4 - samedi 21

* on récupère (offline) un des disques du RAID de super-bc pour le mettre sur super-bc-secours
* mise en production de la nouvelle infrastructure
* test de la bascule d'un lien Internet à l'autre

NM/LBM

Jour 5 - dimanche 22

Jour 6

* gestion des éventuels soucis découlant des changements effectués
* assistance générale :
** impossibilité d'utiliser nos lignes téléphoniques fixes pour appeler l'international
** la connexion des ordinateurs à un réseau wifi empêche de profiter simultanément de la connexion internet et de l'accès aux fichiers (je sais, ça semble bizarre mais Beethoven sait de quoi je parle...)
** Divers

NM/LBM

Jour 7

* suite assistance
* finalisation du serveur secours

NM

* retrait et mise au rencart des serveurs inutilisés (old vz-bc, backup, boukman)

LBM

Jour 8

* mise à jour de la documentation globale (mise à jour du wiki)
* rédaction d'une procédure de bascule en cas de panne du serveur principal

NM

* réunion de synthèse avec la Direction

NM/LBM/Direction

Jour 9

Entretiens et tests de recrutement d'un technicien

NM/LBM/JPM

Jour 10

Jour 11

départ pour Montréal

NM

Réinstallation des postes clients en Trusty

Schémas de l'infrastructure

schémas avant et après

Infra Tech 3.0

Besoin en matériel

  • KVM-IP
  • PCU
  • Disques durs : 4 x 1TB
  • Barrettes mémoires (pour auth-nfs et new-vz-bc)

Annexes

Échanges avec JC sur les soucis de bridges

(13:01:51) moussa.nombre@auf.org/3277039268144837733412656: je suis embourbé dans cette histoire d'interfaces/ponts
(13:02:39) moussa.nombre@auf.org/3277039268144837733412656: hier nuit, finalement tout était bien, mes interfaces de passerelle fonctionnaient
(13:02:54) moussa.nombre@auf.org/3277039268144837733412656: j'y avait accès depuis le lan
(13:03:24) moussa.nombre@auf.org/3277039268144837733412656: et là ce matin, j'arrive au bureau, il y a eu panne de courant, tout a rebooté, et pouf plus rien ne marche
(13:03:28) moussa.nombre@auf.org/3277039268144837733412656: bizarre
(13:04:42) Progfou : ok
(13:04:46) moussa.nombre@auf.org/3277039268144837733412656: dès que tu as 1 minute ...
(13:04:51) Progfou : donc je dirais : forwarding
(13:05:03) Progfou : filtrages sur les bridges
(13:05:08) Progfou : rp_filter
(13:05:11) Progfou : choses de ce genre

(13:06:29) moussa.nombre@auf.org/3277039268144837733412656: 
root@super-bc:~# cat /etc/sysctl.d/local.conf 
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
net.ipv6.conf.all.disable_ipv6 = 1
root@super-bc:~#
(13:11:17) Progfou : vérifies que c'est effectivement actif
(13:11:44) Progfou : car j'avais eu des soucis avec le sysctl -p qui n'appliquait pas mes config' dans /etc/sysctl.d/ (qui est pourtant la bonne place)
(13:12:13) Progfou : (vérifier = grep . /proc/sys/net/bridge/bridge-nf-call-*)
(13:12:46) moussa.nombre@auf.org/3277039268144837733412656: ah ha !
(13:12:53) moussa.nombre@auf.org/3277039268144837733412656: 
root@super-bc:~# sysctl -a | grep bridge
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-filter-pppoe-tagged = 0
net.bridge.bridge-nf-filter-vlan-tagged = 0
net.bridge.bridge-nf-pass-vlan-input-dev = 0

root@super-bc:~# grep . /proc/sys/net/bridge/bridge-nf-call-*
/proc/sys/net/bridge/bridge-nf-call-arptables:1
/proc/sys/net/bridge/bridge-nf-call-ip6tables:1
/proc/sys/net/bridge/bridge-nf-call-iptables:1

(13:13:19) Progfou : ok
(13:13:53) moussa.nombre@auf.org/3277039268144837733412656: faut les déplacer dans le sysctl.conf alors ?
(
(13:14:37) Progfou : oui, mets les dans le principal en attendant de comprendre pourquoi ça se fait pas en dessous

(13:14:52) Progfou : ou sinon mets des appels sysctl dans ton script firewall
(13:15:09) Progfou : ce sera peut-être plus robuste en cas d'upgrade

(13:15:32) moussa.nombre@auf.org/3277039268144837733412656: aurais-tu un exemple pour moi
(
(13:16:06) Progfou : sysctl -w net.bridge.bridge-nf-call-arptables=1

(13:16:36) Progfou : sysctl -w net/bridge/bridge-nf-call-arptables=1
(13:17:01) Progfou : l'intérêt c'est que tu peux copier-coller depuis un chemin parcouru dans le shell (en retirant juste le préfixe /proc/sys/)

(13:21:30) moussa.nombre@auf.org/3277039268144837733412656: comme d'hab : tu es un génie :)
(13:21:48) moussa.nombre@auf.org/3277039268144837733412656: ça  marche tout de suite :)
(13:21:52) moussa.nombre@auf.org/3277039268144837733412656: ouf ouf ouf


ZC/Missions/2018/Décembre/FeuilleDeRoute (dernière édition le 2018-10-25 15:07:49 par MoussaNombre)