Outils pour utilisateurs

Outils du site


logiciel:linux

Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentesRévision précédente
Prochaine révision
Révision précédente
Prochaine révisionLes deux révisions suivantes
logiciel:linux [2011-05-13 18:22] lokbanilogiciel:linux [2014-07-21 20:44] – [Matlab] derval
Ligne 144: Ligne 144:
  
   firefox &   firefox &
- 
-Linux a été mis à jour sur les stations d'enseignement à FC7. Firefox ne fonctionne pas lors du premier lancement pour chaque usager. 
- 
-**Solution : taper la commande Linux après la première exécution** dans une fenêtre de console : 
- 
-  firefixe 
  
 Il y a une règle simple à suivre pour éviter tout problème de profil avec Firefox: utiliser **un et un seul** profil. Dans l'environnement UNIX du DIRO, il n'y a //a priori// rien de particulier à faire pour garantir ceci puisque le profil de Firefox réside dans le compte UNIX de l'usager qui réside sur un serveur central. Malgré tout, il peut arriver de temps à autre qu'au démarrage de Firefox, il demande si l'usager veut créer un nouveau profil ou utiliser un profil existant. Ceci se produit lorsque Firefox ne s'est pas fermé correctement à la dernière exécution ou si une autre instance du logiciel est active sur une autre machine où l'usager est branché. Peu importe la cause, il est **important** de ne pas créer de nouveau profil. Le mieux est de quitter Firefox et, si la situation correspond au deuxième cas, aller fermer l'autre instance. Pour le premier cas (Firefox mal fermé), l'usager doit ouvrir une fenêtre de terminal puis taper : Il y a une règle simple à suivre pour éviter tout problème de profil avec Firefox: utiliser **un et un seul** profil. Dans l'environnement UNIX du DIRO, il n'y a //a priori// rien de particulier à faire pour garantir ceci puisque le profil de Firefox réside dans le compte UNIX de l'usager qui réside sur un serveur central. Malgré tout, il peut arriver de temps à autre qu'au démarrage de Firefox, il demande si l'usager veut créer un nouveau profil ou utiliser un profil existant. Ceci se produit lorsque Firefox ne s'est pas fermé correctement à la dernière exécution ou si une autre instance du logiciel est active sur une autre machine où l'usager est branché. Peu importe la cause, il est **important** de ne pas créer de nouveau profil. Le mieux est de quitter Firefox et, si la situation correspond au deuxième cas, aller fermer l'autre instance. Pour le premier cas (Firefox mal fermé), l'usager doit ouvrir une fenêtre de terminal puis taper :
Ligne 173: Ligne 167:
   * //etc.//   * //etc.//
  
-La version 6 est la version de défaut. Les versions et sont disponibles.+Les versions et 10 sont disponibles.
  
-Pour utiliser la version 7, il faut d'abord taper la commande+Pour utiliser la version 9, il faut d'abord taper la commande
  
-   inclure math-7+   inclure math-9
  
-Pour utiliser la version 8, il faut d'abord taper la commande+Pour utiliser la version 10, il faut d'abord taper la commande
  
-   inclure math-8+   inclure math-10
  
 Vous pouvez exécuter Mathematica en mode graphique avec la commande Vous pouvez exécuter Mathematica en mode graphique avec la commande
Ligne 223: Ligne 217:
   * //etc.//   * //etc.//
  
-Pour lancer le logiciel Matlab version 2009b, la commande est+Pour lancer le logiciel Matlab version 2011a, la commande est
  
     matlab     matlab
  
-Si vous obtenez le message d'erreur+Changez de salle d'ordinateurs si vous obtenez le message d'erreur
  
     Error: Your computer processor is missing the SSE2 instructions that     Error: Your computer processor is missing the SSE2 instructions that
            are required for MATLAB to run correctly.            are required for MATLAB to run correctly.
  
-changez de salle d'ordinateurs ou utilisez la version 2007a.+La version 2014a est disponible par la commande
  
-La version 2007a est disponible par la commande+    matlab14a 
 +     
 +La version 2009b est encore disponible par la commande
  
-    matlab7a+    matlab9b    
  
-===== Base de données =====+===== Bases de données =====
  
 ==== Oracle ==== ==== Oracle ====
Ligne 250: Ligne 246:
   - La commande <code>oradoc</code> démarre Firefox pour consulter la documentation du logiciel.   - La commande <code>oradoc</code> démarre Firefox pour consulter la documentation du logiciel.
  
-===== Systèmes de gestion de versions centralisée et décentralisée =====+==== MySQL ==== 
 + 
 +Plus d'information sur le [[logiciel:mysql|logiciel MySQL]]. 
 +===== Systèmes de gestion de versions =====
  
 ==== Subversion ==== ==== Subversion ====
Ligne 344: Ligne 343:
 ==== Mercurial ==== ==== Mercurial ====
  
-  - [[http://mercurial.selenic.com/|Mercurial]]la gestion est décentralisée.+Le logiciel [[http://mercurial.selenic.com/|Mercurial (hg)]] utilise une gestion décentralisée. 
 + 
 +Dans la description qui suit, la variable **$lab** doit être substitué par le nom du laboratoire et la variable **$hgadm** par le nom de l'usager administrateur créé par le DIRO au moment de la création de la zone de dépôts pour le laboratoire (habituellement hg suivi du nom du lab).  
 + 
 +=== Préparation === 
 + 
 +== Clé ssh pour l'administration == 
 + 
 +Faire parvenir votre clé ssh publique pour vous donner l'accès aux fichiers de gestions des dépôts de votre laboratoire. Si vous n'en avez pas déjà une, dans un terminal, utliser la commande  
 + 
 +<code>ssh-keygen -b 1024 -t dsa</code> 
 + 
 +et faite retour de chariot aussi souvent que nécessaire pour accepter toute les réponses par défaut. Ensuite, envoyez le fichier .ssh/id_dsa.pub au DIRO.  
 + 
 +== Récupération du répertoire des fichiers de configurations == 
 + 
 +Dans un terminal, utilisez la commande  
 + 
 +<code>hg clone $hgadm@version.iro.umontreal.ca:hgadmin</code> 
 + 
 +Pour importer une copie de travail du dépôt des fichiers de gestion hgadmin. Le répertoire a cette structure:  
 + 
 +  * access.conf: contient les règles d'accès. 
 +  * keys/: répertoire contenant les clés ssh publiques des utilisateurs, organisées en sous-répertoires tenant lieu de groupes.  
 + 
 +=== Gestion === 
 + 
 +== Ajout d'un utilisateur == 
 + 
 +Demander à l'usager de vous envoyer [[:logiciel:linux#cle_ssh_pour_l_administration1|une clé publique ssh]]. Ajouter le fichier de la clé dans un sous-répertoire du répertoire keys sous le nom $usager. Dire à hg qu'il y a un nouveau fichier, commettre les changements et les pousser sur le serveur.  
 + 
 +<code>hg add 
 +hg commit -m "ajout usager $usager" 
 +hg push</code> 
 + 
 +== Création de groupes == 
 + 
 +Utiliser la commande mkdir pour créer un sous-répertoire keys/$groupe et y mettre les clés publiques ssh de ceux qui doivent en faire partie. On peut même créer un arborescence plus profonde (i.e. groupe, sous-groupe, sous-sous-groupe, etc.), si cela est nécessaire 
 + 
 +== Groupes prédéfinis == 
 + 
 +Deux sous-répertoires de keys/ ont des accès prédéfinis sur tous les dépôts (avec une exception pour hgadmin). Il se peut que ces sous-répertoires n'existent pas encore lors du premier clonage de hgadmin, il suffit alors de les créer avec un mkdir si on veut les utiliser.  
 + 
 +  * keys/root/: tous les accès possibles sur tous les dépôts  
 +  * keys/users/: accès en lecture et écriture sur tous les dépôts excepté hgadmin  
 + 
 +== Le fichier access.conf == 
 + 
 +Une description des différentes options du fichier access.conf se trouve [[http://dev.lshift.net/paul/mercurial-server/docbook.html#id3886283|ici]]. 
 + 
 +Attention: Lorsque le fichier access.conf est modifié, il doit être commit et repoussé sur le serveur.  
 + 
 +<code>hg commit -m "Modifications configurations..." 
 +hg push</code> 
 + 
 +== Gestion des règles d'accès == 
 + 
 +Le fichier access.conf contient les règles qui définissent les accès pour les différents dépôts. Chaque règle a la forme  
 + 
 +<code>accès repo=glob user=glob</code> 
 + 
 +où  
 + 
 +  * accès est un des types suivants:  
 +    * init: donne les droits de lire, écrire et créer de nouveaux dépôts  
 +    * write: donne les droits de lire et écrire  
 +    * read: donne les droits de lire  
 +    * deny: refuse tous droits  
 +  * repo=glob: chemin relatif menant à un ou plusieurs dépôts  
 +  * user=glob: chemin (à partir de keys) menant à une ou plusieurs clés  
 + 
 +Les expressions glob pour les chemins utilisent * pour représenter un ou plusieurs caractères excluant le /, et %%**%% pour représenter un ou plusieurs caractères incluant le /. Donc, par exemple, repo=labs/* attrape les dépôts labs/aaaa et labs/bbbb mais pas labs/cccc/dddd, alors que repo=labs/%%**%% les attrape tous.  
 + 
 +Par exemple, les trois règles pour les groupes prédéfinis sont  
 + 
 +<code>init user=root/** 
 +deny repo=hgadmin 
 +write user=users/**</code> 
 + 
 +Comme il n'y a aucune condition repo=... dans les règles 1 et 3, elles s'appliquent à tous les dépôts, et de même l'absence de condition user=... dans la 2 fait qu'elle s'applique à tous les utilisateurs.  
 + 
 +== Création de dépôts == 
 + 
 +Si un utilisateur est dans le groupe root ou s'il possède le droit init sur un répertoire de dépôt, alors il peut pousser un nouveau dépôt (vide ou non). Si le dépôt n'existe pas encore  
 + 
 +<code>hg init $nom_repo</code> 
 + 
 +Puis le pousser (à la racine des dépôts, par exemple)  
 + 
 +<code>hg clone $nom_repo $hgadm@version.iro.umontreal.ca/$nom_repo</code> 
 + 
 +=== Utilisation === 
 + 
 +== Clonage d'un dépôt == 
 + 
 +<code>hg clone $hgadm@version.iro.umontreal.ca:$nom_repo</code> 
  
 ==== Git ==== ==== Git ====
  
-  - [[http://git-scm.com/|Git]]la gestion est décentralisée.+Le logiciel [[http://git-scm.com/|Git]] utilise une gestion décentralisée. 
 + 
 +Au cours de ce document, **$lab** doit être substitué par le nom du laboratoire et **$gitadmin** par le nom de l'usager administrateur créé par le DIRO au moment de la création de la zone de dépôts pour le laboratoire (habituellement git suivi du nom du lab).  
 + 
 +=== Préparation === 
 + 
 +== Clé ssh pour l'administration == 
 + 
 +Faire parvenir votre clé ssh publique pour vous donner l'accès aux fichiers de gestions des dépôts de votre laboratoire. Si vous n'en avez pas déjà une, dans un terminal, utliser la commande  
 + 
 +<code>ssh-keygen -b 1024 -t dsa</code> 
 + 
 +et faite retour de chariot aussi souvent que nécessaire pour accepter toute les réponses par défaut. Ensuite, envoyez le fichier .ssh/id_dsa.pub au DIRO.  
 + 
 +== Récupération du répertoire des fichiers de configurations == 
 + 
 +Dans un terminal, utilisez la commande  
 + 
 +<code>git clone $gitadmin@version.iro.umontreal.ca:gitolite-admin.git</code> 
 + 
 +pour importer une copie de travail du répertoire des fichiers de gestion. Le répertoire a cette structure:  
 + 
 + 
 +   * conf/gitolite.conf: contient les groupes d'utilisateurs et les règles d'accès.  
 +   * keydir/: répertoire contenant les clés ssh publiques des utilisateurs.  
 + 
 + 
 + 
 +=== Gestion === 
 + 
 +== Ajout d'un utilisateur == 
 + 
 +Demander à l'usager de vous envoyer [[logiciel:linux#cle_ssh_pour_l_administration2|une clé publique ssh]]. Ajouter le fichier de la clé dans le répertoire keydir sous le nom $usager.pub. Dire à git qu'il y a un nouveau fichier, commettre les changements et les pousser sur le serveur.  
 + 
 +<code> 
 +git add keydir 
 +git commit -m "ajout usager $usager" 
 +git push origin master 
 +</code> 
 + 
 +== Le fichier conf/gitolite.conf == 
 + 
 +La description complète du fichier conf/gitolite.conf se trouve [[http://sitaramc.github.com/gitolite/doc/gitolite.conf.html|ici]]. 
 + 
 +**Attention:** Lorsque le fichier conf/gitolite.conf est modifié, il doit être commit et repoussé sur le serveur 
 + 
 +<code> 
 +git add conf/gitolite.conf 
 +git commit -m "Modifications configurations..." 
 +git push origin master 
 +</code> 
 + 
 +== Gestion des groupes d'utilisateurs == 
 + 
 +Ajouter, dand le fichier conf/gitolite.conf, des lignes comme celle-ci:  
 + 
 +<code> 
 +@groupe1 = $usager1 $usager2 ... 
 +</code> 
 + 
 +== Gestion des règles d'accès et création de dépôts == 
 + 
 +Pour chaque dépôt, il doit exister dans le conf/gitolite.conf un bloc  
 + 
 +<code> 
 +repo $nom_repo 
 +      RW+= @admin 
 +      RW   = @contrib $usager5 ... 
 +      R    = @all 
 +</code> 
 + 
 +où les permissions sont R (read), W (write) et + (rewind, i.e. non-fast forward push). Le groupe @all est un groupe spécial qui inclut automatiquement tous les usagers dont la clé est valide. On peut donner des permissions spécifiques à une branches en la nommant, i.e. RW branch$ = @groupe..  
 + 
 +Lors du push, tous les dépôts nommés dans le fichier seront créés s'ils n'existent pas encore.  
 + 
 +=== Utilisation === 
 + 
 +== Clonage d'un dépôt == 
 + 
 +<code>git clone $gitadmin@version.iro.umontreal.ca:$reponame.git</code> 
 + 
  
 ===== Logiciels disponibles au DIRO ===== ===== Logiciels disponibles au DIRO =====
Ligne 360: Ligne 536:
 | **chmp** | Pour changer son mot de passe | | **chmp** | Pour changer son mot de passe |
 | **[[:labs:grappe|cluster]]** | Réservation de machines parallèles | | **[[:labs:grappe|cluster]]** | Réservation de machines parallèles |
-| **[[http://www.ilog.com/products/cplex/|cplex]]** | Outil de programmation linéaire CPLEX. Pour l'utiliser le logiciel CPLEX, il faut taper les commandes (environnement de recherche seulement) : <code>inclure cplex +| **[[http://www.ilog.com/products/cplex/|cplex]]** | Outil de programmation linéaire CPLEX. Pour l'utiliser le logiciel CPLEX, il faut taper les commandes (environnement de recherche seulement) : <code>inclure cplex9-j6   (pour la version 9) ou 
-cplex</code> |+inclure cplex12     (pour la version 12) 
 +                    (puis) 
 +cplex               (pour lancer le logiciel)</code> |
 | **[[http://wiki.daimi.au.dk/cpntools/cpntools.wiki|cpn]]** | Colored Petri Net, version 4, génie logiciel | | **[[http://wiki.daimi.au.dk/cpntools/cpntools.wiki|cpn]]** | Colored Petri Net, version 4, génie logiciel |
 | **[[http://www.gnu.org/software/ddd/|ddd]]** | Débogueur | | **[[http://www.gnu.org/software/ddd/|ddd]]** | Débogueur |
logiciel/linux.txt · Dernière modification : 2020-01-08 21:42 de royjuli