PrimTux3 pour Rapberry Pi: tests

[Philippe Dpt35]

Ce problème de proxy ne se pose qu'avec le RPi, pas avec un PC ?

[ThierryM]

C'est un cas particulier car je n'ai installé que des Primtux sur Raspberry Pi dans cette école avec serveur Amonecole. Il n'y a que là que j'ai eu à configurer un proxy.

[Philippe Dpt35]

C'est pour savoir si ce correctif est à appliquer au RPi seuls, ou également à toutes les versions de PrimTux.

Avant de toucher aux fichiers de configuration, je voudrais toutefois être certain que cela ne provoque pas "d'effets secondaires". Pour un cas particulier, faut-il prendre le risque de provoquer un bug pour tous ? Un tutoriel pour ce cas particulier n'est-il pas préférable ?

Je m'interroge notamment sur l'IP 192.168.0.3 et le port 3128
Sont-ils liés à ton installation particulière, ou ont-ils une valeur générique ? Dans ce dernier cas, à quoi correspondent-ils ?

[Steph]

Rien à voir avec firefox, ce sont les ports et adresse d'écoute de dansguardian sur tinyproxy. Le problème ne semble pas être là mais dans le déblocage des paramètres réseau, qui fontionnent très bien sur PC.

[Philippe Dpt35]

Si ça fonctionne correctement sur PC, je ne vois pas pourquoi ça ne fonctionnerait pas sur RPi, la configuration étant la même, sauf particularité insoupçonnée de Raspbian.

[Steph]

Je viens de refaire le test, quand on désactive on a bien possibilité de régler le proxy.

[ThierryM]

Le serveur Amonecole/Eclair/Amonecole+ est basé sur la solution EOLE qui est testé sur Grenoble (avec image LTSP de Primtux pour des clients légers évoqué dans le fil suivant : http://forum.primtux.fr/viewtopic.php?id=1211). Et comme l'a souligné Steph, c'est le réglage par défaut pour DansGuardian qui est le proxy utilisé par les déclinaisons EOLE : ces ports ne sont pas exotiques .
J'avais été déjà obligé de faire ce réglage manuel du proxy pour une version Raspbian classique pour pouvoir la mettre à jour sur ce réseau (d'où mon tutoriel qui m'a servi pour Primtux car sans ça impossible de mettre à jour).

[Philippe Dpt35]

En regardant ce qu'ils font sur Grenoble:
https://gitlab.tetras-libre.fr/tetras-li...imtux-eole

on voit que les modifications suggérées par ThierryM sont effectuées dans les scripts de pré et postinstall, et cela ne concerne pas que les RPi.
Cela serait donc nécessaire pour toute machine passant par EOLE.

Maintenant, faut-il l'intégrer de base dans les futures versions de PrimTux, sachant que pour ce type de besoin, il y aura sans doute intervention d'un "spécialiste" qui saura quoi faire ?

On peut aussi envisager un script mis à disposition sur PrimTux.

Qu'en pensez-vous ?

[ThierryM]

L'idéal serait de pouvoir régler directement les différents proxy en mode administrateur (mais ça demanderait certainement du développement pour un nombre limité d'utilisateur).
Peut-être que juste une documentation pour des "spécialistes" suffirait...
Ou mieux, en cas d'utilisation derrière un proxy EOLE, un script (car mon réglage manuel poste par poste est fastidieux) à lancer dans Primtux (dans un terminal, ce qui est à la portée d'un "spécialiste" débutant ).
Oups, je n'avais pas lu l'idée de script déjà suggérée par Philippe.

[Steph]

Oui un script mais non intégré parce que ça risque de dérouter les novices.

[Philippe Dpt35]

Le script sera facile à faire, car il suffit de reprendre et d'adapter ce qu'ils ont déjà fait sur Grenoble.
Je veux bien m'en charger.

[ThierryM]

Oui un script mais non intégré parce que ça risque de dérouter les novices.

Pourquoi ne pas l'intégrer sans le lancer automatiquement, une sorte d'agent dormant ?
Il suffirait alors de le lancer juste en cas de besoin (sans avoir besoin de le chercher, de le télécharger, de le mettre sur une clé USB, avec les bons droits, sachant qu'on n'a pas accès à Internet à cause justement du problème du proxy). On installerait Primtux de façon classique et une fois l'installation faite, l'administrateur pourrait lancer le script à n'importe quel moment (ça peut être utile aussi si on prépare les ordi à un endroit et qu'ensuite on les déploie à l'école).
Et même mieux, un script réversible pour revenir à la version classique sans proxy ?

[Steph]

Parce que PrimTux est une distribution qui se veut simple. Rien que le panneau d'administration les 2/3 des utilisateurs ne le trouvent pas ou ne l'utilisent pas, peut-être parce qu'il est déjà trop complet et donc déroutant. Je ne compte pas les demandes d'aide qui concernent une fonctionnalité de base. Il ne faut pas multiplier les fonctionnalités, mais au contraire, simplifier leur accès. L'utilisateur qui veut bricoler pour passer derrière eole sait déjà ce qu'il doit faire. On peut lui sumplifier la tache avec un script, mais on doit tendre vers une distribution encore plus simple, et ce n'est pas en intégrant des outils qui relèvent somme toute d'une personnalisation qu'on la rendra plus accessible. Il faut une base solide personnalisable, mais non encore personnalisée et destinée au plus grand nombre out of the box.

[Philippe Dpt35]

Je pense que ThierryM veut dire le placer de façon invisible, sans aucune entrée de menu quelconque. Par exemple dans un répertoire /usr/share/doc/primtux.

On pourrait y placer quelques scripts utiles aux administrateurs, dont le lien ne serait donné que dans les tutos spécialisés du site ou du forum. ça faciliterait la vie des administrateurs qui, on le voit, sont tout de même assez nombreux sur le forum.

Invisible pour les utilisateurs lambda, utile pour les installateurs !

[Steph]

Oui là on peut, pour le reste à trop multiplier les fonctionnalités on risque de perdre des utilisateurs.

[ThierryM]

Entièrement d'accord avec toi Steph.
Edit : Tout à fait Philippe (j'étais en train d'écrire quand tu as posté ton précédent message), c'était exactement ma pensée.
Voilà pourquoi, les outils "techniques" ne relevant pas directement de l'enseignant⋅e ne devraient pas apparaître tout le temps car ils surchargent et déroutent du fait de leur technicité. Par exemple, régler un proxy, un dossier partagé, ne se font qu'une fois en général et ne relèvent pas de choix pédagogiques contrairement à la personnalisation des Handy-Menus.

Peut-être qu'il faudrait pour alléger les interfaces, un accès "administrateur⋅rice" et un autre accès "enseignant⋅e" ? Mais cela demande de faire un tri en listant ce qui relève du choix des enseignant⋅e⋅s et ce qui est indépendant de ce choix (c'est-à-dire dépendant de contraintes techniques sur lesquelles ils⋅elles n'ont pas de prise). De toute façon, l'installation de Primtux demande des compétences que la majorité des enseignant⋅e⋅s n'ont pas, à l'heure actuelle (et à l'avenir) : il faudra toujours un "bricoleur" au départ.

[mothsart]

Je suis dac sur les remarques de Thierry : si on veut simplifier, il faut séparer la partie "enseignant⋅e" de celle de "technicien" même si ça arrive souvent que ça soit la même personne.

[Philippe Dpt35]

J'ai fait un script téléchargeable ici:
http://www.primtux.fr/Documentation/scri...xy-eole.sh

L'édition de /etc/sudoers étant risquée sans visudo, j'ai utilisé la solution plus sécurisée de créer un fichier dans /etc/sudoers.d
Au niveau sécurité, c'est préférable, ce fichier pouvant facilement être supprimé pour des besoins d'administration.

proxy-eole.sh

Code :

#!/bin/bash

# Ajoute les variables d'environnement
echo "export http_proxy=192.168.0.3:3128
export https_proxy=192.168.0.3:3128
export ftp_proxy=192.168.0.3:3128" >>/etc/environment

echo 'Defaults env_keep = "http_proxy https_proxy ftp_proxy"' > /etc/sudoers.d/fix-env-var

# Ajoute le proxy pour apt
fichier=/etc/apt/apt.conf.d/10proxy
echo 'Acquire::http::proxy "http://192.168.0.3:3128/";' >"$fichier"
echo 'Acquire::https::proxy "https://192.168.0.3:3128/";' >>"$fichier"
echo 'Acquire::ftp::proxy "ftp://192.168.0.3:3128/";'  >>"$fichier"
chmod 0440 "$fichier"

J'ai bien sûr vérifié qu'il fait correctement les opérations indiquées, mais je ne peux vérifier si les opérations effectuées sont correctes.
Peux-tu tester cela, ThierryM ?

[ThierryM]

Merci Philippe.
Je teste dès que possible et fais un retour.
Cordialement,

[ThierryM]

Adieu a totes,
Le script de Philippe marche comme attendu (exécution dans un terminal). Merci beaucoup. C'est un sacré gain de temps (le plus long a été de le récupérer , d'où l'intérêt d'intégrer ce fichier directement pour une exécution encore plus rapide par l'administrateur en cas de besoin : le fait que le proxy bloque l'accès Internet complique sacrément le déploiement) ! Du coup, va falloir que je me lance dans l'étude des scripts... ^-^

Concernant le réglage du proxy dans Firefox, effectivement proxy-protect-firefox-esr fonctionne : j'ai eu la fenêtre proposant d'activer ou de désactiver la protection. Je ne sais pas ce qu'il s'est passé... Je vais pouvoir finaliser l'installation des 6 Raspi dans l'école. Désolé pour le bruit.
Cordialement.

Thierry

[ThierryM]

Petit retour in situ (de ma classe). J'ai toujours un problème avec le proxy pour Firefox. Je ne peux lancer l'utilitaire de déprotection qu'en ligne de commande (impossible via "Préférences Élèves" ou via le menu "Système" : après avoir saisi le mot de passe, rien ne se passe). La désactivation fonctionne, par contre la ré-activation, non. Voici un extrait de mon terminal :

Code :

root@primtux5:/home/administrateur# cd /usr/local/bin/primtux/
root@primtux5:/usr/local/bin/primtux# ./proxy-protect-firefox-esr
root@primtux5:/usr/local/bin/primtux# ./proxy-protect-firefox-esr
root@primtux5:/usr/local/bin/primtux# ./proxy-protect-firefox-esr
grep: s/pref/#pref/g: Aucun fichier ou dossier de ce type
/usr/local/bin/primtux/proxy-protect-esr: 37: [: grep: unexpected operator
root@primtux5:/usr/local/bin/primtux# ./proxy-protect-firefox-esr
grep: s/pref/#pref/g: Aucun fichier ou dossier de ce type
/usr/lib/firefox-esr/defaults/pref/local-settings.js:pref("general.config.obscure_value", 0); // grise les paramètres de modification du proxy
/usr/lib/firefox-esr/defaults/pref/local-settings.js:pref("general.config.filename", "mozilla.cfg");
/usr/local/bin/primtux/proxy-protect-esr: 37: [: grep: unexpected operator
root@primtux5:/usr/local/bin/primtux#

En l'état ce n'est pas bien grave car Firefox (sans protection pour le proxy) fonctionne pour les élèves. J'ai dû aller dans chaque session des élèves pour le paramétrer. Remarque : pour l'utilisateur 01, il faut démarrer Pépit (qui fonctionne en local) pour avoir un accès à Firefox, si l'on veut utiliser des sites Internet pour des cycles 1 En fait il y a l'icône Firefox à côté de celle de Pepit.

En administrateur, Chromium ne fonctionne pas : bizarre car sous d'autres systèmes, c'est le fichier /etc/environment qui sert à indiquer le proxy...

Cordialement,
Thierry

[Philippe Dpt35]

Bizarre, ça fonctionne correctement chez moi, aussi bien depuis l'administration système que depuis le menu système.
Tu es sûr que la fenêtre ne se trouve pas cachée ?

Quant à tes messages d'erreur:
- il faut être administrateur, donc la commande n'est pas reconnue sans sudo.
- comme tu es dans un dossier système, inutile de mettre le ./
Lance directement la commande
sudo proxy-protect-firefox-esr

[Philippe Dpt35]

J'oubliais:

En administrateur, Chromium fonctionne aussi sans problème chez moi.
En revanche, sur le RPi, il lui arrive parfois de mettre une éternité avant de démarrer, et je ne sais pas pourquoi. Comme ça n'est pas systématique, difficile d'en trouver la cause !

[ThierryM]

Non, la fenêtre n'est pas cachée.
Je ne pense pas que ce soit un problème de "sudo" car je passe par le terminal administrateur.

Pour Chromium, il se lance bien mais pas d'accès à Internet : typiquement une erreur de proxy. Du coup, je l'ai remplacé par Firefox dans la session administrateur.
Tous ces problèmes ne seraient-ils pas dû au fait que j'ai cloné une image "dégradée" ? Il faudrait que je refasse une nouvelle image et retester pour voir.

[Philippe Dpt35]

Je ne pense pas que ce soit un problème de "sudo" car je passe par le terminal administrateur.

Si j'avais été plus attentif, j'aurais effectivement vu l'indication du root !