Considérations générales sur le fonctionnement en mode serveur

Avant d’aborder la mise en œuvre de Zentyal et LTSP, il convient de poser quelques bases, relatives au matériel réseau, à sa prise en charge, aux services fournis par Zentyal, LTSP …

Cet article est le premier de la catégorie « serveur » ; ce que j’entends par serveur est simplement une machine qui rend au moins un service à une ou plusieurs autres machines. Par exemple, partage de fichiers, synchronisation d’horloges, hébergement de sauvegardes. Les machines servies sont les clients du serveur.

Continue reading

La session frenchKISS : éléments de base

Pour situer, voici un aperçu de l’objectif :

Ambiance-Humanity

Pour obtenir un environnement de travail fonctionnel et sans fioritures, il nous faut :

  • un gestionnaire de fenêtres, Openbox, assisté par ClipIt pour la gestion du presse-papier
  • une barre des tâches / horloge / systray, Tint2, accompagnée du menu développé par nos soins, fkMenu
  • un gestionnaire de fichiers, Nautilus, complété par Udisks-Glue pour le montage automatique de périphériques USB
  • un gestionnaire de fond d’écran, Nitrogen

Continue reading

Installation : système et logiciels supplémentaires

Nous partons sur la base d’une 12.04.3 en 32 bits, avec l’ISO d’installation Ubuntu Desktop, pour faire une installation complètement … normale. On installe le « logiciel tiers », les paquets linguistiques et les mises à jour.

A propos du partitionnement

Il n’y a pas de recette magique, il s’agit simplement de savoir ce que l’on compte faire de sa machine. Un simple poste de travail se contentera d’une partition séparée pour /home, de façon à sauvegarder facilement ses données. Un serveur sera plus sûr avec un partitionnement plus complexe. L’important est de savoir quels services auront besoin de quelle place au fil du temps (penser aux journaux, aux données, éventuellement à l’emplacement d’une base de données, au nombre d’utilisateurs de la machine).

Pour le swap, j’ai un principe tout bête : en avoir au moins autant que la RAM, si l’on souhaite mettre en hibernation sa machine. Par ailleurs, le prix de la RAM est tel que le mieux est de s’arranger pour n’avoir jamais besoin de swapper …

A propos de la mémoire vive

En théorie, 512Mo sont le minimum pour le programme d’installation d’Ubuntu ou une session live ; il est tellement facile d’activer ZRAM qu’il serait bête de s’en priver. En mode « science fiction », on peut imaginer que cela permette -vraiment- d’installer sur une machine avec moins de 512Mo depuis le même media d’installation.

Dans une session Ubuntu, ouvrir un terminal (Ctrl+Alt+t), lancer un shell superutilisateur (sudo -i), installer zram-config (apt-get install zram-config) et éditer le fichier /etc/init/zram-config.conf. La ligne 20 de ce fichier initialise la variable mem ; c’est cette variable qui définit la quantité de RAM allouée au « RAMswap » (je viens de déposer le nom). Comme indiqué dans le fichier, on alloue la moitié de la RAM à cette fonction, ce qui me semble énoooooorme et que je propose de réduire à un quart. C’est tout bête :

mem=$(((totalmem / 2 / ${NRDEVICES}) * 1024))

devient

mem=$(((totalmem / 4 / ${NRDEVICES}) * 1024))

Quoi de plus simple, on remplace / 2 par / 4 ? Un petit redémarrage et ça gaze.

Continue reading

Situons le contexte

Rappel de l’objectif :

  • produire un remix d’Ubuntu LTS, à jour, contenant quelques applis « inévitables », quelques paquets inévitables (codecs …), quelques réglages.
  • Inclure un environnement utilisateur économe en ressources, correspondant aux usages « historiques » (barre des tâches, menu) mais en évitant un look trop austère ou rétro, et que l’utilisateur ne puisse pas casser en modifiant un réglage.
  • Donner la possibilité de faire facilement d’une machine un serveur de clients légers et un serveur d’infrastructure (partage d’accès Internet, de fichiers, d’applications …), ce qui inclut la gestion en masse d’utilisateurs et de leurs environnements de travail.
  • faire en sorte que le système soit accessible à distance.

Continue reading

Changements en cours

Depuis de longs mois désormais, la nouvelle version de frenchKISS se fait attendre … alors même que je travaille dessus presque quotidiennement. Les raisons sont multiples et ont déjà été évoquées :

Certains logiciels mis en œuvre dans les versions précédentes ont subi d’importantes évolutions qui remettent en question le travail d’intégration déjà réalisé.

Par ailleurs, force est de reconnaître que depuis quelques mois, tout n’évolue pas de façon positive dans le petit monde des logiciels libres : il s’agit d’être très prudent vis à vis de la qualité de certains composants qui, depuis des lustres, n’appelaient pourtant aucune attention particulière.

En outre, le développement d’un environnement utilisateur, et d’outils de gestion de cet environnement, ouvre régulièrement de nouvelles pistes à explorer. Il me manque manifestement un cahier des charges suffisamment précis, et arrêté, pour produire quelque chose de fini avant quelques millions d’années.

La solution : structurer, et documenter.

Structurer, cela veut dire progresser pas à pas, de façon claire et exhaustive, depuis un système de base jusqu’au produit final.

Documenter, cela veut dire tout publier ici, plutôt que d’entasser des notes dans un cahier complètement surchargé et plein de redites, ce qui passe par un petit travail sur la mise en page, le système mis en œuvre jusqu’à maintenant demandant trop de travail sur des images avant publication …

Je m’en vais donc lancer les opérations pas plus tard que tout de suite, et l’on verra où tout ça nous mènera.