La nouvelle distribution éducative pour débutants et initiés.

Vous n'êtes pas identifié(e).

Annonce

PRIMTUX3 i386 EST DISPONIBLE SUR SOURCEFORGE.
Somme MD5: 93ef32d6c63215a3dd015419bf456eac

#26 06-04-2016 14:29:43

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Je teste et je me rends compte que le paquet ltsp n'existe pas, en cherchant on me dit d'installer ce paquet: ltsp-server-standalone => peux-tu confirmer?
Merci!

Hors ligne

#27 07-04-2016 10:23:34

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Bonjour, ltsp-server-standalone installe un système quasi-complet avec serveur X et mate comme bureau par défaut. Sur Primtux, ltsp-server suffit.

Par contre, après pas mal de temps à tester  et à comprendre, je laisse tomber ltsp qui n'est qu'une grosse collection de scripts genre usine à gaz servant juste à faciliter l'installation de l'ensemble, qui, si l'on sait ce que l'on fait, peut se faire en utilisant les outils classiques. Et de plus mal documenté (j'entends par là qu'on comprend à peine comment ça fonctionne). En fait tout passe par ssh via un script ldm qui initie une connexion graphique.

Enfin je parle pour mon usage personnel avec un serveur de base et un primtux chrooté. Pour l'instant ça fonctionne nickel sans ltsp mais avec seulement ldm depuis un client classique (un ordi) via Xephyr, pour l'instant dans le cadre des tests. Mais il y a un problème lors du changement d'environnement (de prof à mini par ex) qui fait planter la connexion ssh (ou ldm, je ne sais pas). Je pense qu'avec primtux liberté, ce ne doit pas être le cas puisque les comptes sont séparés. De plus il faut créer autant de compte prof (prof1, prof2, ... par ex) qu'il y a de postes clients car il ne doit pas être possible que plusieurs utilisateurs (aka plusieurs sessions ssh) puissent utiliser une même application en même temps sur un même compte. Pour ce qui est de Berryterminal ou de Raspian sur raspberry, nous n'avons pas encore réussi. Sur Berryterminal, pas de connexion sur le serveur et comme il n'y a pas de tty autre que celui de la connexion LDM, il n'y a pour l'instant pas moyen de voir les logs. Mais ça va certainement venir... Sur Raspian, j'ai réussi une connexion graphique via ssh, mais les proportions de l'écran (du bureau) ne sont pas terribles (le bandeau de gauche du bureau bouffe sur celui de l'appli lancée) et le visuel des applis lancées sur raspbian restent en fond sauf à les réduire, elles passent en barre de tâches.

Attention au script ltsp-build-client qui installe le système chrooté : à la moindre erreur de la connexion internet pendant le téléchargement des paquets, il stop et on est obligé de tout recommencer. Quand on a une connexion satellite avec forfait limité, c'est rageant et coûteux. Mais pour un client berryterminal, c'est inutile d'installer un chroot puisqu'il utilise la racine de l'hôte. En fait ltsp-build-client ne sert aussi qu'à faciliter, en théorie, le travail d'installation puisque qu'il est multi-plateformes (Debian, Ubuntu, Gentoo, ...). Il commence par installer un système de base dans le chroot via debootstrap puis à partir de la configuration du système hôte il installe les paquets nécessaires à un environnement utilisateur.Donc rien que ne puisse faire quelqu'un qui maîtrise Unix avec les outils classiques.

Petite remarque perso (troll) : LTSP est fait par l'équipe Canonical avec cet esprit qui tend à vouloir faire ressembler Linux (Ubuntu) à windows sous prétexte de le mettre à la portée de tout le monde, en complexifiant par des collections de scripts, et donc en le fragilisant, un système Unix qui à la base a une philosophie de simplicité : Un programme ne fait qu'une chose, mais il le fait bien. Il suffit de regarder Unity pour comprendre (et le virer).

À suivre ...

Dernière modification par moricef1 (07-04-2016 11:43:26)

Hors ligne

#28 25-08-2016 15:58:56

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Bonjour, nous avons bien avancés après quelques temps de pause. Nous avons laissé complètement tombé LTSP pour ne garder que LTSP Display Manager (LDM), le gestionnaire de connexion de LTSP.
Ceci est valable pour primtux eiffel et raspberry sous raspbian wheezy avec sysvinit (et non pas systemd).

Les clients raspberry wheezy

Sur le raspberry, on commence par installer l'image sur la carte sd puis au premier lancement, on lance raspi-config pour étendre le système de fichier racine à toute la partition /, puis configurer les locales en fr UTF8, le clavier en français azerty et le fuseau horaire.
On installe ensuite les paquets suivants : xserver-xorg pulseaudio alsa-base et ldm :

apt-get update && apt-get upgrade && apt-get install xserver-xorg pulseaudio alsa-base ldm

Ensuite on force l'adresse MAC  de la carte réseau dans /boot/cmdline.txt en rajoutant à la fin :

smsc95xx.macaddr=B8:27:EB:XX:XX:XX

(juste changer les 3 derniers couples de valeurs)

Dans /etc/dhcpcd.conf, on change :

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid

Commenter la valeur duid et dé-commenter la valeur clientid pour avoir une demande basée sur l'adresse mac auprès du serveur dhcp


Pour le son via pulseaudio :

On ajoute en tant qu'admin si il n'y est pas déjà le fichier /etc/asound.conf :

pcm.!default {
        type hw
        card 0
        device 0
}

ctl.!default {
        type hw
        card 0
        device 0
}

Afin de démarrer pulseaudio en tant que système, modifier le fichier /etc/default/pulseaudio en changeant
PULSEAUDIO_SYSTEM_START=1 et DISALLOW_MODULE_LOADING=0:

# Start the PulseAudio sound server in system mode.
# (enables the pulseaudio init script - requires that users be in the
# pulse-access group)
# System mode is not the recommended way to run PulseAudio as it has some
# limitations (such as no shared memory access) and could potentially allow
# users to disconnect or redirect each others' audio streams. The
# recommended way to run PulseAudio is as a per-session daemon. For GNOME/KDE/
# Xfce sessions in Ubuntu Lucid/10.04, /etc/xdg/autostart/pulseaudio.desktop
# handles this function of automatically starting PulseAudio on login, and for
# it to work correctly your user must *not* have "autospawn = no" set in
# ~/.pulse/client.conf (or in /etc/pulse/client.conf). By default, autospawn
# is enabled. For other sessions, you can simply start PulseAudio with
# "pulseaudio --daemonize".
# 0 = don't start in system mode, 1 = start in system mode
PULSEAUDIO_SYSTEM_START=1

# Prevent users from dynamically loading modules into the PulseAudio sound
# server. Dynamic module loading enhances the flexibility of the PulseAudio
# system, but may pose a security risk.
# 0 = no, 1 = yes
DISALLOW_MODULE_LOADING=0

pour autoriser les flux audio en réseau pour pulseaudio, on rajoute à la fin du fichier /etc/pulse/system.pa  :

load-module module-native-protocol-tcp auth-ip-acl=192.168.0.0/16;127.0.0.1

et dans la section réseau de /etc/pulse/default.pa :

### Network access (may be configured with paprefs, so leave this commented
### here if you plan to use paprefs)
#load-module module-esound-protocol-tcp
load-module module-native-protocol-tcp auth-ip-acl=192.168.0.0/16;127.0.0.1
#load-module module-native-protocol-tcp
#load-module module-zeroconf-publish

Afin de lancer le script qui va configurer les variables d'environnement nécessaires et les différents processus au niveau runlevel 2, ajouter à /etc/rc.local :


#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

# Print the IP address
_IP=$(hostname -I) || true
if [ "$_IP" ]; then
  printf "My IP address is %s\n" "$_IP"
fi

if [ "`runlevel`" = "N 2" ]; then
  /bin/bash /root/primtux_client.sh
fi

exit 0

Le script /root/primtux_client.sh qui est lancé :

#!/bin/sh

# Préparer le son
# Verifier /etc/asound.conf : device 0
# Verifier /etc/pulse/system.pa : load-module module-native-protocol-tcp
# Finalement, on le lance via 'init', voir /etc/default/pulseaudio
# /usr/bin/pulseaudio -D --system

# Préparer le server X (affichage)
/usr/bin/Xorg &
DISPLAY=:0
export DISPLAY

# attendre que X se lance
/bin/sleep 5

# Variables pour LDM

LDM_USERNAME=prof
export LDM_USERNAME
LDM_XSESSION=startfluxbox
export LDM_XSESSION
LDM_PASSWORD=tuxmaitre
export LDM_PASSWORD

# LDM ne semble pas prendre en compte login & passwd

LDM_SSHOPTIONS="-o StrictHostKeyChecking=no -o CheckHostIP=no"
export LDM_SSHOPTIONS
LDM_SERVER=192.168.2.1
export LDM_SERVER


# Lancer LDM qui redémarre automatiquement si il est stoppé
while true
do
  /usr/sbin/ldm
done

Rendre le script executable :

chmod +x /root/primtux_client.sh
Le serveur headless debian jessie

(Je n'explique pas tout ici pour le serveur)

Le serveur est installé sur 2 disques durs de 1 TO chacun avec 2 cartes réseau.
Les disques sont partionnés avec raid 1 logiciel et lvm.
Configuration du serveur isc-dhcp-server :

#
# Default LTSP dhcpd.conf config file.
#

authoritative;                                     

subnet 192.168.xx.0 netmask 255.255.255.0 {
    range 192.168.xx.10 192.168.xx.50;            # Plage d'adresse desservie par le serveur DHCP du serveur LTSP
    option domain-name "aaaa.bbbbb.ccc";    # nom DNS du réseau pédagique
    option domain-name-servers 192.168.xx.xx;         # adresse IP du serveur DNS 
    option broadcast-address 192.168.xx.255;}
        host rasp1 {
        hardware ethernet B8:27:EB:XX:XX:XX;
        fixed-address 192.168.xx.xx;
        }       

        host rasp2 { 
        hardware ethernet B8:27:EB:XX:XX:XX;
        fixed-address 192.168.xx.xx;
        }

        host rasp3 {
        hardware ethernet B8:27:EB:XX:XX:XX;
        fixed-address 192.168.xx.xx;
        }       

        host rasp4 {
        hardware ethernet B8:27:EB:XX:XX:XX;
        fixed-address 192.168.xx.xx;
        }

Création du conteneur primtux dans /var/lib/container/primtux en y copiant une primtux Eiffel déjà installée sur une autre partition.
Pour le lancer au démarrage du système via systemd-nspawn, il faut l'activer ainsi :

# systemctl enable systemd-nspawn@primtux.service

et pour le lancer manuellement :

# systemctl start systemd-nspawn@primtux.service

Dans le /home du container primtux, j'ai créer ensuite autant de compte utilisateurs prof (prof1,prof2 ,prof3, …) qu'il y a de clients raspberry.
Dans chaque compte prof, il faut indiquer où aller chercher le serveur de son pulseaudio - c’est-à-dire sur les raspberry : ça se fait dans ~.fluxbox/startup en ajoutant
PULSE_SERVER=$LTSP_CLIENT
export PULSE_SERVER :

#!/bin/sh
#
# fluxbox startup-script:
#
# Lines starting with a '#' are ignored.

# Change your keymap:
xmodmap "/home/primtux/.Xmodmap"

# Applications you want to run with fluxbox.
# MAKE SURE THAT APPS THAT KEEP RUNNING HAVE AN ''&'' AT THE END.
#
# unclutter -idle 2 &
# wmnd &
# wmsmixer -w &
# idesk &
#
# Debian-local change:
#   - fbautostart has been added with a quick hack to check to see if it
#     exists. If it does, we'll start it up by default.
which fbautostart > /dev/null
if [ $? -eq 0 ]; then
    fbautostart
fi

PULSE_SERVER=$LTSP_CLIENT
export PULSE_SERVER

# And last but not least we start fluxbox.
# Because it is the last app you have to run it with ''exec'' before it.
exec /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 &
exec xfce4-panel &
exec lxpanel &
exec rox -p 1 &
# exec /usr/bin/BNE-Linux &
# exec /usr/bin/handymenu-mini &
# exec /usr/bin/handymenu-super &
# exec /usr/bin/handymenu-maxi &
exec /usr/bin/accueil &
exec fluxbox
# or if you want to keep a log:
# exec fluxbox -log "/home/primtux/.fluxbox/log"

Voilà ! Le flux vidéo n'est pas terrible et ça reste à optimiser, il n'y a pas de verrouillage du pavé numérique dans la fenêtre de connexion de ldm, et il faut surtout fermer la session primtux sans l'arrêter ni la redémarrer. Globalement ça fonctionne plutôt bien tout en sachant ce que l'on a fait. Et surtout ça s'adapte bien à Primtux Eiffel et son système de scripts pour changer de bureau (passer de prof à mini,ou maxi, etc)
On verra comment tout cela peut fonctionner avec systemd sous raspbian jessie, mais c'est pas gagné.
To be continued ...

Dernière modification par moricef1 (18-01-2018 19:48:43)

Hors ligne

#29 25-08-2016 18:07:29

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Merci pour ce retour. Par contre, concernant le startup de fluxbox, as-tu possibilité de mettre ces lignes:


PULSE_SERVER=$LTSP_CLIENT
export PULSE_SERVER

avec un & à la fin de chacune APRÈS exec /usr/bin/accueil &.
Parce que ça décale toutes les lignes et du coup si on demande l'activation d'un handymenu ou de l'accueil au démarrage ça ne changera pas la bonne ligne.

Hors ligne

#30 31-08-2016 18:08:53

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

J'ai essayé avec

(...)
exec /usr/bin/accueil &
PULSE_SERVER=$LTSP_CLIENT &
export PULSE_SERVER &
(...)

les variables d'environnement ne sont pas prises en compte.
Par contre juste après :

# Change your keymap:
xmodmap "/home/primtux/.Xmodmap"

PULSE_SERVER=$LTSP_CLIENT
export PULSE_SERVER

donc sans & à la fin puisque avant la série d'exec, et là c'est ok. Remarque, j'aurais tout aussi bien pu le mettre en début de script...

Dernière modification par moricef1 (31-08-2016 18:10:59)

Hors ligne

#31 31-08-2016 18:10:07

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Il va falloir les caser ailleurs, tu as essayé sous /etc/init.d ?

Hors ligne

#32 31-08-2016 18:14:13

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

avant la série d'exec ça pose un problème?
parce que dans /etc/init.d/ il me semble qu'on avait essayé sans succès; peut-être à cause de system.d qui n'utilise plus les scripts d'init, mais les xxxxx.service, non?

Dernière modification par moricef1 (31-08-2016 18:17:34)

Hors ligne

#33 31-08-2016 18:24:19

4kristof6
Membre
Inscription : 18-09-2015
Messages : 30

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

moricef1 a écrit :

To be continued ...

Bonjour,

J'ai bien lu votre retour sur LTSP et je me dis que cette réflexion va dans le bon sens (de ne pas installer "l'usine à gaz" si pas besoin voire compliquer la situation)... Je l'avais réalisé sous Jessie et cela fonctionnait bien mais dans notre cas, nous avons déjà la distrib munie des logiciels et services.

Serait-il possible d'avoir un coup de main sur les services à lister afin de se passer de LTSP et permettre la connexion des clients à un serveur Primtux via LDM ?
J'ai installé la version bêta, consulté ce que fourni le paquet "ldm-server" https://packages.debian.org/jessie/misc/ldm-server mais certain paquet "recommandés" n'ont certainement pas lieu d'être.

J'ai listé : ldm-server isc-dhcp-server tftpd-hpa nbd-server squashfs-tools ; que pourrait-il manquer ?

Hors ligne

#34 31-08-2016 18:29:07

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

moricef1 a écrit :

avant la série d'exec ça pose un problème?
parce que dans /etc/init.d/ il me semble qu'on avait essayé sans succès; peut-être à cause de system.d qui n'utilise plus les scripts d'init, mais les xxxxx.service, non?

Tous les démarrages automatiques y sont suivant les numéros de lignes à commenter ou pas, alors oui c'est gênant. Est-ce que tu peux tenter avec un script qui contient tes commandes et que tu mets juste avant exec fluxbox voir après en mettant & à la fin de exec fluxbox?

Hors ligne

#35 01-09-2016 17:11:50

thierry
Membre
Inscription : 14-06-2016
Messages : 206

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Si l'on désire exporter des variables d'environnement, celles-ci doivent être renseignées en premier.
La fonction exec sert à remplacer la parenté du shell courant par la commande qui le suit sans retour à celui-ci.
Il y a perte de filiation du processus fils avec celle du père qui n'est pas tenu de mettre un terme au processus fils initié par exec lors de sa propre extinction (processus père).
ex.:

exec xterm &

lance un terminal (xterm) qui n'est pas détruit suite à la fermeture du shell qui l'a généré et qui peut continuer à être exploité.
(c'est le & final qui permet ceci: passage en arrière plan avec retour immédiat au premier plan, le shell courant)
Le nouvel xterm hérite cependant des variables d'environnement qui ont été préalablement exportées par la commande:

export my_VAR="toto"
exec xterm &

le nouvel xterm n'a plus de lien de parenté avec son processus père (le shell) qui peut être stoppé sans arrêter pour autant le fils (le nouvel xterm).

Autre test:

exec /bin/sh

Et vous saisirez la différence, avec et sans & final.
(le père est auto détruit par le fils qui prend sa place)

Dernière modification par thierry (01-09-2016 17:46:36)

Hors ligne

#36 03-09-2016 08:10:46

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

moricef1 a écrit :

J'ai essayé avec

(...)
exec /usr/bin/accueil &
PULSE_SERVER=$LTSP_CLIENT &
export PULSE_SERVER &
(...)

les variables d'environnement ne sont pas prises en compte.
Par contre juste après :

# Change your keymap:
xmodmap "/home/primtux/.Xmodmap"

PULSE_SERVER=$LTSP_CLIENT
export PULSE_SERVER

donc sans & à la fin puisque avant la série d'exec, et là c'est ok. Remarque, j'aurais tout aussi bien pu le mettre en début de script...

Je viens de remarquer qu'il y avait un gros tas de ligne commentées dans cette partie. Du coup il n'y a rien qui t'empêche de mettre tes commandes à la place par exemple de:
# unclutter -idle 2 &
# wmnd &

aux lignes 13 et 14. Si tu remplaces, les numéros de lignes ne changent pas et tout reste en ordre.

Hors ligne

#37 05-09-2016 18:16:30

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

J'ai fait comme tu l'indiques ci-dessus mais sans les & car avec ce n'est pas pris en compte et je ne vois pas pourquoi des déclarations d'environnement devraient être traitées comme un programme. J'ai vérifié le démarrage des sessions enfants avec handymenu, je ne vois pas de pb.

Par contre, dans un autre registre (dois-je ouvrir un autre post?), je n'arrive pas à configurer les locales sur fr_FR.UTF-8, même avec dpkg-reconfigure locales. Elles restent sur POSIX par défaut. Il faut dire que j'ai repris mes .bashrc, était-ce dans ceux installés avec primtux? Toujours est-il que firefox est enanglais ainsi que bien des applis.

Sinon je voudrais ne garder que les entrées "fermer la session" et "annuler" dans primtux shutdown menu. Où est le fichier de conf?

Hors ligne

#38 05-09-2016 18:17:48

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

/usr/local/bin/primtux

Hors ligne

#39 06-09-2016 20:19:16

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Pour Eiffel 1ère version, c'est dans /usr/share/shutdown/ où il faut modifier  /usr/share/shutdown/shutdown_gui.glade et /usr/share/shutdown/shutdown.py
Dans /usr/share/shutdown/shutdown_gui.glade, j'ai supprimé les ligne 23 à 84 pour effacer les boutons arrêt et reboot. Pour positionner les 2 boutons restant au centre  j'ai changé les variables de positionnement <property name="x"> et <property name="y"> en prenant celles des boutons centraux reboot et logout.  Pour LogoutButtonx=36, y=86  et x=41, y=91 pour image3; pour CancelButton x=36, y=165 et x=41, y=168 pour image4.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE glade-interface SYSTEM "glade-2.0.dtd">
<!--Generated with glade3 3.4.1 on Sat Feb 16 01:52:03 2008 -->
<glade-interface>
  <widget class="GtkWindow" id="ShutdownBox">
    <property name="width_request">350</property>
    <property name="height_request">310</property>
    <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
    <property name="title" translatable="yes">PrimTux Shutdown Menu</property>
    <property name="resizable">False</property>
    <property name="modal">True</property>
    <property name="window_position">GTK_WIN_POS_CENTER</property>
    <property name="icon">help-browser.png</property>
    <property name="skip_taskbar_hint">True</property>
    <property name="skip_pager_hint">True</property>
    <property name="urgency_hint">True</property>
    <property name="deletable">False</property>
    <property name="opacity">0</property>
    <child>
      <widget class="GtkLayout" id="layout1">
        <property name="visible">True</property>
        <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
     <child>
          <widget class="GtkButton" id="LogoutButton">
            <property name="width_request">210</property>
            <property name="height_request">52</property>
            <property name="visible">True</property>
            <property name="can_focus">True</property>
            <property name="receives_default">True</property>
            <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
            <property name="label" translatable="yes">_  Fermer la session</property>
            <property name="use_underline">True</property>
            <property name="response_id">0</property>
            <signal name="clicked" handler="on_LogoutButton_clicked"/>
          </widget>
          <packing>
            <property name="x">36</property>
            <property name="y">86</property>
          </packing>
        </child>
        <child>
          <widget class="GtkImage" id="image3">
            <property name="width_request">62</property>
            <property name="height_request">47</property>
            <property name="visible">True</property>
            <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
            <property name="stock">gtk-stop</property>
          </widget>
          <packing>
            <property name="x">41</property>
            <property name="y">91</property>
          </packing>
        </child>
        <child>
          <widget class="GtkButton" id="CancelButton">
            <property name="width_request">210</property>
            <property name="height_request">52</property>
            <property name="visible">True</property>
            <property name="can_focus">True</property>
            <property name="receives_default">True</property>
            <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
            <property name="label" translatable="yes">_Annuler</property>
            <property name="use_underline">True</property>
            <property name="response_id">0</property>
            <signal name="clicked" handler="on_CancelButton_clicked"/>
          </widget>
          <packing>
            <property name="x">36</property>
            <property name="y">165</property>
          </packing>
        </child>
        <child>
          <widget class="GtkImage" id="image4">
            <property name="width_request">50</property>
            <property name="height_request">44</property>
            <property name="visible">True</property>
            <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
            <property name="stock">gtk-undo</property>
          </widget>
          <packing>
            <property name="x">41</property>
            <property name="y">168</property>
          </packing>
        </child>
        <child>
          <widget class="GtkImage" id="image5">
            <property name="width_request">67</property>
            <property name="height_request">285</property>
            <property name="visible">True</property>
            <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
            <property name="pixbuf">logo.png</property>
            <property name="icon_size">2</property>
          </widget>
          <packing>
            <property name="x">261</property>
            <property name="y">14</property>
          </packing>
        </child>
        <child>
          <widget class="GtkHSeparator" id="hseparator1">
            <property name="width_request">207</property>
            <property name="height_request">20</property>
            <property name="visible">True</property>
            <property name="events">GDK_POINTER_MOTION_MASK | GDK_POINTER_MOTION_HINT_MASK | GDK_BUTTON_PRESS_MASK | GDK_BUTTON_RELEASE_MASK</property>
          </widget>
          <packing>
            <property name="x">39</property>
            <property name="y">225</property>
          </packing>
        </child>
      </widget>
    </child>
  </widget>
</glade-interface>

Dans /usr/share/shutdown/shutdown.py, j'ai effacé les lignes 49 et 50 au cas où :

"on_RebootButton_clicked"   : self.on_reboot,
"on_ShutdownButton_clicked" : self.on_shutdown,

Sinon je ne trouve toujours pas comment j'ai pu perdre les locales.Tous les fichiers /etc/environment et /etc/default/locale sont renseignés avec : LANG="fr_FR.UTF-8"

Dernière modification par moricef1 (06-09-2016 20:55:56)

Hors ligne

#40 06-09-2016 20:45:56

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

@4kristof6 :
Ce qui nous a motivé à laisser tomber LTSP pour ne garder que le paquet ldm coté client, c'est le choix d'un serveur headless (sans serveur graphique donc minimaliste) sous Debian stable. Ce serveur devant lancer plusieurs conteneurs simultanément (par exemple Primtux plus une autre Jessie avec Xorg, ou une opensuze, etc) et surtout parce que Primtux, qui n'est pas conçu pour cet usage et qui est encore jeune donc forcément encore à parfaire, ne soit pas à la base d'un serveur en production.
Si Primtux est à la base du serveur, pourquoi ne pas utiliser LTSP qui fonctionne tout de même très bien après tout? ltsp-server devrait suffire,plutôt que ltsp-server-standalone.

Mais en fait je m'aperçois que je ne comprend pas votre question ... Est-ce que vous voulez reproduire notre installation de serveur avec des clients de type anciens PC à la place  des raspberry?

Dernière modification par moricef1 (06-09-2016 21:06:17)

Hors ligne

#41 06-09-2016 20:46:17

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Ah ben oui tiens, ce paquet est tellement ancien... Et le bin est dans /usr/bin
Avec les locales j'en ai tellement bavé... J'ai ajouté des FR un peu partout! J'ai un user-dirs.locale dans le /home/.config de chaque utilisateur qui contient fr_FR.

Hors ligne

#42 06-09-2016 20:59:56

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

En fait j'en viens à me demander si ce n'est pas plutôt systemd-nspawn qui impose les locales du système hôte. Je vais vérifier.

Hors ligne

#43 08-09-2016 12:37:46

4kristof6
Membre
Inscription : 18-09-2015
Messages : 30

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

moricef1 a écrit :

@4kristof6 : Mais en fait je m'aperçois que je ne comprend pas votre question ... Est-ce que vous voulez reproduire notre installation de serveur avec des clients de type anciens PC à la place  des raspberry?

Oui, c'est cela, un serveur et des pc sans disques durs en clients légers smile
J'avais ce système sous Debian Jessie l'année dernière (tout le package ltsp) et j'ai voulu proposer Primtux pour le côté adapté à plusieurs niveaux de l'école primaire.

J'ai bien avancé sur la bêta puisque je me connecte à présent au serveur ; j'ai installé ltsp-server et cela fonctionne.
Le seul problème que je rencontre (et pas des moindres), c'est que l'environnement de bureau ne remonte pas sur les clients légers ou plutôt pas comme attendu sad
J'ai un bureau vide avec le logo de Debian en bas à droite, qq outils dans la barre des tâches et seul un clic-droit dans l'espace me donne accès aux applications...

Si qq a une idée, je suis preneur wink

Hors ligne

#44 13-09-2016 16:40:08

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

@4kristof6 :
Alors dans ce cas je ne peux pas trop vous aider. Les raspberry ont une carte sd en guise de disque dur avec raspbian wheezy lite installée.
Pour les pc diskless, ça passe par un boot pxe et un montage tftp. J'ai fais ça un jour pour un système de gestion de parc avec GLPI, mais dans le cas présent je ne saurais être d'aucune utilité. Désolé.

Hors ligne

#45 13-09-2016 16:43:03

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Pour ma problématique de locale fr_FR.UTF-8, je l'ai résolu en plaçant une ligne LANG=fr_FR.UTF-8 dans .fluxbox/startup à la suite des autres variables PULSE_SERVER

J'ai changé le sources.list pour y mettre tous les dépots officiels jessie afin de pouvoir installer firefox-esr en remplacement d'iceweasel et sortir du contrôle parental que je n'arrivais pas à contourner.

deb http://httpredir.debian.org/debian jessie main
deb-src http://httpredir.debian.org/debian jessie main

deb http://httpredir.debian.org/debian jessie-updates main
deb-src http://httpredir.debian.org/debian jessie-updates main

deb http://security.debian.org/ jessie/updates main
deb-src http://security.debian.org/ jessie/updates main

mais je crains que lors d'une màj, libreoffice primtux, par exemple, soit remplacé part la version standard de debian. Dans quels dépots se trouve la version Primtux de libreoffice? Est-ce dans

deb http://depot.primtux.fr/repo/debs/ PrimTux main

?

J'ai changé aussi le moteur de recherche Qwant Junior qui me semblais bien trop restreint en matière de résultats pour Startpage avec filtrage. Et pour avoir un filtrage bien plus complet, je pense que je vais installer Ipfire sur le raspberry qui me reste.

Quant au retour au multi-utilisateurs de la dernière version d'eiffel, est-ce la suppression des scripts de changement de bureau (qui vont très bien avec la connexion via ldm puisqu'il n'y a pas de demande de mot de passe pour les comptes enfants)?

Dernière modification par moricef1 (13-09-2016 17:31:26)

Hors ligne

#46 13-09-2016 16:44:04

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Bon à savoir!

Hors ligne

#47 13-09-2016 17:43:04

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Alors libreoffice est celui de Debian, et oui les scripts de changement de bureau ne serviront plus.
Quant à Ipfire, il utilise la même liste que dansguardian.

Hors ligne

#48 13-09-2016 18:19:58

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Pour libreoffice, l'interface des écoles est dans les fichiers de conf .config/libreoffice/4/user/ecole/? Enfin peu importe, si je fais une màj de libreoffice, ça n'écrasera pas l'interface des écoles?
Pour Ipfire sur Raspberry, je pourrais le mettre en tête de réseau qu'il puisse servir aussi pour la mairie (2 postes) et la classe de la directrice d'école qui préfère conserver ses 4 postes sous windows. Et aussi parce que j'ai pas mal utilisé Ipcop à une certaine époque.

Hors ligne

#49 13-09-2016 20:04:51

Steph
Administrateur
Inscription : 03-06-2015
Messages : 3 751

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Oui Ipfire c'est une distribution firewall quoi.
Non l'interface ne sera pas écrasée avec une mise à jour (j'ai testé avec libreoffice 5).

Hors ligne

#50 14-09-2016 09:16:16

moricef1
Membre
Inscription : 19-01-2016
Messages : 48

Re : Utiliser Primtux comme serveur LTSP pour connecter des clients légers!

Exit Ipfire sur raspberry, en pratique ça ne fonctionne pas à cause de la faiblesse du débit ethernet limité à 100Gb/s et des ports usb partagés : http://forum.ipfire.org/viewtopic.php?t=12541

Hors ligne

Pied de page des forums