Communications client-serveur lors de l'installation » Historique » Version 10
Christophe Martin, 06/02/2012 07:46
1 | 1 | Christophe Martin | h1. Communications client-serveur lors de l'installation |
---|---|---|---|
2 | |||
3 | Dans le principe : |
||
4 | |||
5 | 4 | Christophe Martin | Tout démarre sur le client. |
6 | 2 | Christophe Martin | |
7 | 7 | Christophe Martin | L'application, le script de setup, le paquet, est appelé « le setup » ci après. |
8 | 1 | Christophe Martin | |
9 | 10 | Christophe Martin | Le setup crée si besoin un utilisateur local @bckpciuem@ et lui donne les privilèges suffisants pour qu'il puisse faire les sauvegardes et les restaurations. Cet utilisateur a dans son home un script spécial appelé @rsyncsend.sh@ (il est dans le dépôt git) |
10 | 1 | Christophe Martin | |
11 | 6 | Christophe Martin | le setup contient une clef secrète ssh appelée @register-key@ |
12 | |||
13 | 7 | Christophe Martin | Le setup obtient de manière interactive le logon de l'utilisateur principal de l'ordinateur (logon défini dans l'annuaire LDAP). |
14 | 5 | Christophe Martin | |
15 | 9 | Christophe Martin | Le setup fait une connexion ssh (voir la section « exemple de commande et dialogue » plus bas su cette page) |
16 | 4 | Christophe Martin | * au serveur de sauvegarde, |
17 | * en utilisant le clef secrete @register-key@ |
||
18 | * vers le compte @backuppc@ |
||
19 | * demande l'exécution d'une hypothétique commande de la forme OS:logon |
||
20 | |||
21 | 1 | Christophe Martin | Le serveur exécute alors une commande spéciale associée à la clef secrete, sous le compte backuppc. |
22 | 5 | Christophe Martin | |
23 | 4 | Christophe Martin | Cette commande récupère le paramètre OS:logon via la variable d'environnement SSH_ORIGINAL_COMMANDE, passée par sshd |
24 | |||
25 | Cette commande effectue alors toute une série de vérifications sur le client, l'OS demandé et le logon, etc... et si tout va bien répond : |
||
26 | 1 | Christophe Martin | <pre> |
27 | success |
||
28 | </pre> |
||
29 | 4 | Christophe Martin | Sur la première ligne. |
30 | 3 | Christophe Martin | |
31 | 6 | Christophe Martin | NB Tout autre réponse du serveur doit être considérée comme un message d'erreur. +L'ensemble de cette ligne et les suivantes constituent alors le message d'erreur+. |
32 | 1 | Christophe Martin | |
33 | 4 | Christophe Martin | Quand la première ligne est « @success@ » viennent ensuite dans un ordre non spécifié des lignes de la forme @mot-clef:valeur@. pour l'instant sont définis les mots-clef suivants : |
34 | 1 | Christophe Martin | * @key@ Il s'agit de la clef publique correspondant à la clef privée utilisée par le serveur pour effectuer les sauvegardes. Cette clef devra être utilisée dans le fichier @~bckpciuem/authorized_keys@ pour affecter les connexions du serveur à la commande de backup/restauration « @rsyncsend.sh@ » |
35 | 3 | Christophe Martin | * @url@ L'URL que l'utilisateur doit visiter pour personnaliser ses sauvegardes. |
36 | 4 | Christophe Martin | |
37 | 7 | Christophe Martin | Le setup sur le client analyse la réponse du serveur et prend les mesures qui s'imposent. Au minimum, la clef ssh publique doit être associée à la commande @rsyncsend.sh@ de l'utilisateur local @bckpciuem@ |
38 | 3 | Christophe Martin | |
39 | 2 | Christophe Martin | h1. exemple de commande et dialogue |
40 | 3 | Christophe Martin | |
41 | <pre> |
||
42 | su bckpciuem -c "env SSH_AUTH_SOCK= ssh -x -a -i register-key -l backuppc dugong mac:cmartin" >"/tmp/resultat.$$" 2>&1 |
||
43 | </pre> |
||
44 | Le serveur répond |
||
45 | <pre> |
||
46 | success |
||
47 | url: http://dugong.univ-brest.fr/backuppc/?host=dormeur |
||
48 | 9 | Christophe Martin | key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDEBV4um ... jb5Rnf2F7W/0z backuppc server to client dormeur ssh key" |
49 | 1 | Christophe Martin | </pre> |
50 | 8 | Christophe Martin | |
51 | h1. Messages d'erreurs |
||
52 | |||
53 | Les messages d'erreurs commencent toujours par la variable SSH_CONNECTION qui contient les adresses et ports sources et destinations de la connexion ssh. |
||
54 | exemple |
||
55 | <pre> |
||
56 | 82.254.212.144 49631 134.158.240.3 22 |
||
57 | </pre> |
||
58 | |||
59 | Les messages d'erreurs se retrouvent systématiquement dans le journal système. Il sont émis avec la structure @local3@, le niveau varie de @notice@ à @err@ |
||
60 | |||
61 | La plupart des messages d'erreurs sont faciles à comprendre. certains autres sont plus difficiles les voici : |
||
62 | |||
63 | * @ostype is unknown@ la commande passée par ssh est non vide mais n'est pas de la forme OS:xxxx ou OS ne fait pas partie des choses reconnues par le serveur. Le prblème se trouve dans le setup du client qui ne lance pas la bonne commande ssh. |
||
64 | * @ bad user request :@ Le logon passé au serveur dans la commande @OS:logon@ par le setup du client n'existe pas dans l'annuaire LDAP de l'IUEM. L'utilisateur s'est sans doute trompé en donnant son identifiant. |
||
65 | * @invalid DNS name for this IP@ le PTR de l'adresse IP du client n'est pas une adresse en @.univ-brest.fr.@. Ceci ne devrait jamais se produire |
||
66 | * @refusing to re-register client host with username@ La machine client est déjà enregistrée sur le serveur mais avec un autre nom d'utilisateur que celui demandé cette fois ci. Pour éviter le vol de sauvegarde par usurpation d'identité, On refuse cette opération. il faut alors intervenir sur le serveur pour régler le problème. (Par exemple: effacer les anciennes sauvegardes et manuellement retirer la machine du fichier hosts) |
||
67 | * @Could not register@ Le serveur est très mal en point car un simple "echo ...... >>..../hosts" n'a pas pu être effectué. Soit il manque de place, soit les permissions ne sont pas bonnes sur le serveur. |
||
68 | * @could not generate config file.@ Le serveur est très mal en point. Il est impossible de créer un fichier temporaire de quelques dizaines octets. |