Une Debian GNU/Linux ultra light

Support Debian
#1

Bonjour à tous (et surtout toutes :wink: ),

Je me décide enfin à me créer une Debian perso et ultra light.

J’installe donc une Wheezy amd64 netinstall sans rien de plus (tout décoché lors de l’installation des ensembles de paquets).

Je souhaite un environnement graphique, j’installe donc en post-install sans modifier sources.list: xorg, openbox, obconf, obmenu, menu, menu-xdg, pcmanfm, xterm, midori, tint2, idesk, slim, quelques autres fioritures et toutes leurs dépendances (dans les 600 paquets en plus des 200 de base je crois).

Je reboote, me logge avec slim et là, plus rien, écran noir sans aucun menu au clic droit de la souris, clavier qui ne sert à rien, curseur en forme de croix.

Je réinstalle le tout sans slim et là j’arrive à démarrer openbox avec un startx en root, pas de soucis particuliers, j’ai le menu du clic droit, etc… mais pas en utilisateur normal, j’ai un “connection refused” comme ici:
Xinit: unable to connect to X server: connection refused
Xinit: server error

Plutôt qu’un problème de driver comme suggéré ici http://www.debian-fr.org/debian-openbox-pour-installation-minimal-pb-envi-graphique-t45576.html je pense à un problème de droits, puisque je n’ai pas de soucis en root.

première question: comment pourrais-je avoir un openbox fonctionnel en utilisateur normal puisque que ça fonctionne avec root?

seconde question: pourquoi quand j’installe slim tout “plante”? (je ne suis pas sûr que ça plante puisque le curseur en croix bouge en même temps que la souris mais rien d’autre ne répond en apparence)

J’ai une connaissance relativement modeste des entrailles de Linux, j’ai lu pas mal de tutos sur ubuntuforums, phollow, archwiki et d’autres mais je ne trouve pas l’info ou je m’y perds…

Pourriez-vous m’aider s’il vous plaît?

précisions:

  • ma Debian light devrait fonctionner sur ma machine car j’utilise la même version (Wheezy amd64 gnome3) en dur qui fonctionne parfaitement
  • la machine: Asus M2V Green, CPU AMD DualCore 3.1Ghz, 4x1Go RAM OCZ, GPU nVidia 8400GS, pas de SSD, graveur multi sata

Merci beaucoup par avance!

DarkGagan.

#2

Bonjour,
de mémoire, lorsque tu installes openbox, il ne crée un fichier de conf que pour le compte root.
Il faut que tu recopies le rep .openbox dans le /home de l’utilisateur courant, en changeant évidement l’owner et le groupe.

#3

Tu as regardé s’il y avait des exemples dans /usr/share/doc/openbox ?

#4

Démarrer Xorg en root n’est pas conseillé. Vérifie les permissions du fichier ~/.Xauthority de ton compte utilisateur classique.

Voir aussi:
lancement-openbox-uniquement-en-root-t46950.html
le-systeme-ne-peut-se-recuperer-t47103.html

#5

Bonsoir tout le monde,

Merci beaucoup pour vos retours c’est super cool!

Il me fallait un .xsession dans /home/MONUSER, j’ai fait un echo openbox-session > /home/MONUSER/.xsession
J’ai rajouté aussi contrib et non-free dans mon /etc/apt/sources.list et ai installé firmware-linux au cas où.

@piratebab,
J’ai fait ça: (login en root en console)

mkdir /home/MONUSER/.config

mkdir /home/MONUSER/.config/openbox

cp -r /etc/xdg/openbox/* /home/MONUSER/.config/openbox

ma question subsidiaire: comment je change sans faire de bétises l’owner et le groupe? J’ai testé sous MONUSER chown -R MONUSER:users > chown -R MONUSER:MONUSER (comme recommandé ici: http://www.debian-fr.org/chown-impossible-t45964.html mais ça n’a pas l’air d’être ça. J’ai testé chown -R MONUSER * et j’ai vérifié avec ls -l /home/MONUSER/.config/openbox/rc.xml ça me donne -rw-r–r--, je pense qu’il manque des trucs.

@thuban,
J’ai DL le package d’openbox sous un autre PC, l’ai décompressé, ai trouvé /usr/share/doc/openbox/config.html dans le répertoire de décompression et là ça dit l’ordre de recherche des fichiers de config par openbox en installation par package, soit dans /home d’abord, puis /etc/xdg/openbox, d’où la recopie de ces fichiers de /etc/xdg/openbox vers /home/MONUSER/.config/openbox comme préconisé par piratebab

@Zbf,
Les permissions de mon .Xauthority donnent -rw-------, ça ne s’annonce pas bon je pense, je doit peut-être changer l’owner et le groupe aussi?
Concernant tes liens (très instructifs!), je fais exactement comme le premier mais je bloque au .xinitrc, je ne sais pas quoi mettre dedans et ne trouve pas d’exemples. Comme tu as pu le lire plus haut, j’ai pu créer le .xsession dans /home/MONUSER. Je précise que je ne compte pas mettre de gestionnaire de connexion type slim/lightdm…, je voudrais en fait démarrer automatiquement sous MONUSER au démarrage sans saisir quoi que ce soit (apparement possible avec mingetty que je verrai plus tard quand openbox démarrera sous MONUSER). Le 2e lien je pense qu’il est très utile mais je décroche par manque de connaissance, je ne sais pas à quoi servent les commandes donc je n’ai pas tenté pour ne pas tout casser :stuck_out_tongue:

Résumé à aujourd’hui: ça ne marche pas encore mais on a avancé un peu et j’ai appris beaucoup!
Si vous pouvez encore m’aider un petit peu pour la suite ça serait super-méga-cool :wink:

#6

Si tu souhaites un démarrage automatique sur ta session graphique, ça n’est pas gênant de mettre LightDM.
Tu as aussi la solution “nodm”, mais c’est un peu moins bien foutu (quand on quitte la session, ou qu’on redémarre nodm, ça cafouille)

Pour les fichiers .xinitrc (ou .xsession, je ne sais jamais), chez moi j’ai:

Tu peux remplacer i3 par le nom du programme qui invoque openbox.

Note: je n’ai pas lu attentivement ton dernier post.

#7

Bonjour,

J’ai trouvé pour .xinitrc, il faut mettre dans mon cas…
“exec openbix-session”, le même que dans .xsession, sauf que je n’ai pas besoin pour l’instant de .xsession car apparement c’es slim et xdm qui l’utilisent.

J’ai donc réussi à obtenir une interface graphique (openbox de base) mais encore une fois, qu’en root, j’ai des erreurs type connection refused en user normal.

J’ai lu que pour que ça fonctionne en user il fallait faire les manip en…user. normal. Le truc c’est qu’en user quand je fais un “su root” et je tape mon pass root, il me refuse systématiquement les droits root. Pourtant sur mon système de test mon pass root n’est composé que de minuscules et de chiffres, 8 caractères au total. Je sais ce n’est pas un pass root mais on s’en fiche c’est un test, ça sera reformaté quand tout fonctionnera ou tout ne fonctionnera plus :stuck_out_tongue:

Une idée pour mon problème de droits root avec su en user?

#8

Je pige pas.

Tu peux te connecter en root depuis un terminal (CTRL+ALT+F1), login: root
Et tu ne peux pas te connecter si tu fais dans un terminal (utilisateur standard):

???

Ton mot de passe à des lettres susceptibles de gêner selon si mode qwerty/azerty ? Tu peux vérifier ça en tapant ce que tu veux dans le champ login.

#9

Les fléaux que tu as causés par usage inconsidéré du compte root sous X doivent être réparés avec les droits de root.
luser ne peut pas changer le propriétaire des fichiers qui ne lui appartiennent plus.
root le peut. (# : root)

(tu remplaces luser par le nom de l’utilisateur concerné.)

#10

@Zbf,

Je n’ai pas de login manager donc au boot j’ai un prompt qui demande un login.
Quand je saisis login root et password root je peux lancer une session graphique avec un startx, même si je sais que ce n’est pas bien.
Quand je saisis login USER et password USER je ne peux pas lancer une session graphique avec un startx, j’ai le probléme de permissions cité plus haut. Cependant j’ai quand même un shell. Dans ce shell, si je saisis su ou su - ou su root, le shell demande le pass root logiquement. Je le tape, les caractères sont correctement saisis j’ai vérifié, ça me répond pass incorrect en gros et je reviens au prompt. Et c’est comme ça aussi sur ma Debian Gnome sur une autre machine. Pour lancer une commande en root j’utilise gksu sur cette machine et là ça fonctionne.
Est-ce que j’ai raté quelquechose avec su? C’est pourtant simple, juste un pass root, mais ça marche pas…

@etxeberrizahar,
c’est pile poil ce que que je cherchais sur l’utilisation correcte de chown, merci! Quand je pourrai utiliser su sous mon USER je pourrai lancer cette commande après avoir copié le contenu de /etc/xdg/openbox dans /home/USER/.config/openbox et ainsi peut-être enfin avoir openbox fonctionnel sous USER et poursuivre mon bidouillage :stuck_out_tongue:

#11

Tu n’as pas besoin de session graphique pour lancer les commande cp, chown …
Le login root en tty suffira.

SU

/etc/pam.d/su

#
# The PAM configuration file for the Shadow `su' service
#

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

# Uncomment this to force users to be a member of group root
# before they can use `su'. You can also add "group=foo"
# to the end of this line if you want to use a group other
# than the default "root" (but this may have side effect of
# denying "root" user, unless she's a member of "foo" or explicitly
# permitted earlier by e.g. "sufficient pam_rootok.so").
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
# auth       required   pam_wheel.so

# Uncomment this if you want wheel members to be able to
# su without a password.
# auth       sufficient pam_wheel.so trust

# Uncomment this if you want members of a specific group to not
# be allowed to use su at all.
# auth       required   pam_wheel.so deny group=nosu

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on su usage.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account    requisite  pam_time.so

# This module parses environment configuration file(s)
# and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# 
# parsing /etc/environment needs "readenv=1"
session       required   pam_env.so readenv=1
# locale variables are also kept into /etc/default/locale in etch
# reading this file *in addition to /etc/environment* does not hurt
session       required   pam_env.so readenv=1 envfile=/etc/default/locale

# Defines the MAIL environment variable
# However, userdel also needs MAIL_DIR and MAIL_FILE variables
# in /etc/login.defs to make sure that removing a user 
# also removes the user's mail spool file.
# See comments in /etc/login.defs
#
# "nopen" stands to avoid reporting new mail when su'ing to another user
session    optional   pam_mail.so nopen

# Sets up user limits according to /etc/security/limits.conf
# (Replaces the use of /etc/limits in old login)
session    required   pam_limits.so

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session

Passages qui nous intéressent :
force users to be a member of group root before they can use `su’.
obligation de faire partie de $GROUPE-ROUE pour pouvoir user de su
[mono]# auth required pam_wheel.so[/mono]

members of a specific group to not be allowed to use su at all.
$GROUPE-DES-INTERDITS-DE-SU
[mono]# auth required pam_wheel.so deny group=nosu[/mono]
Ces passages sont-ils commentés (#) chez toi ?
Est-ce que tu as retouché /etc/pam.d/su, /etc/login.defs ou /etc/securetty ?

GKSU
Le succès de gksu ne garantit pas que su opère.
Gksu est capable de [mono]su[/mono] … et de [mono]sudo[/mono].
Voir ce qu’il en est de sudo pour luser.

En session graphique, s’assurer que gksu ne soit pas un déguisement de sudo

#12

gksu et su c’est différent.
Le 1er te demande le mot de passe utilisateur (comme [mono]sudo[/mono]) pour exécuter une commande avec les droits root.
Le 2nd te demande le mot de passe root pour “devenir” root.

Si tu fais:

ça fonctionne ? Quel mot de passe entres-tu ?

#13

[quote=“etxeberrizahar”]Tu n’as pas besoin de session graphique pour lancer les commande cp, chown …
Le login root en tty suffira.

 #  cp -r /etc/xdg/openbox  /home/luser/.config/openbox

SU

/etc/pam.d/su

#
# The PAM configuration file for the Shadow `su' service
#

# This allows root to su without passwords (normal operation)
auth       sufficient pam_rootok.so

# Uncomment this to force users to be a member of group root
# before they can use `su'. You can also add "group=foo"
# to the end of this line if you want to use a group other
# than the default "root" (but this may have side effect of
# denying "root" user, unless she's a member of "foo" or explicitly
# permitted earlier by e.g. "sufficient pam_rootok.so").
# (Replaces the `SU_WHEEL_ONLY' option from login.defs)
# auth       required   pam_wheel.so

# Uncomment this if you want wheel members to be able to
# su without a password.
# auth       sufficient pam_wheel.so trust

# Uncomment this if you want members of a specific group to not
# be allowed to use su at all.
# auth       required   pam_wheel.so deny group=nosu

# Uncomment and edit /etc/security/time.conf if you need to set
# time restrainst on su usage.
# (Replaces the `PORTTIME_CHECKS_ENAB' option from login.defs
# as well as /etc/porttime)
# account    requisite  pam_time.so

# This module parses environment configuration file(s)
# and also allows you to use an extended config
# file /etc/security/pam_env.conf.
# 
# parsing /etc/environment needs "readenv=1"
session       required   pam_env.so readenv=1
# locale variables are also kept into /etc/default/locale in etch
# reading this file *in addition to /etc/environment* does not hurt
session       required   pam_env.so readenv=1 envfile=/etc/default/locale

# Defines the MAIL environment variable
# However, userdel also needs MAIL_DIR and MAIL_FILE variables
# in /etc/login.defs to make sure that removing a user 
# also removes the user's mail spool file.
# See comments in /etc/login.defs
#
# "nopen" stands to avoid reporting new mail when su'ing to another user
session    optional   pam_mail.so nopen

# Sets up user limits according to /etc/security/limits.conf
# (Replaces the use of /etc/limits in old login)
session    required   pam_limits.so

# The standard Unix authentication modules, used with
# NIS (man nsswitch) as well as normal /etc/passwd and
# /etc/shadow entries.
@include common-auth
@include common-account
@include common-session

Passages qui nous intéressent :
force users to be a member of group root before they can use `su’.
obligation de faire partie de $GROUPE-ROUE pour pouvoir user de su
[mono]# auth required pam_wheel.so[/mono]

members of a specific group to not be allowed to use su at all.
$GROUPE-DES-INTERDITS-DE-SU
[mono]# auth required pam_wheel.so deny group=nosu[/mono]
Ces passages sont-ils commentés (#) chez toi ?
Est-ce que tu as retouché /etc/pam.d/su, /etc/login.defs ou /etc/securetty ?

=> non je n’ai en rien modifié ces fichiers, honnêtement je découvre leur existence :blush:

GKSU
Le succès de gksu ne garantit pas que su opère.
Gksu est capable de [mono]su[/mono] … et de [mono]sudo[/mono].
Voir ce qu’il en est de sudo pour luser.

 $ sudo -l

En session graphique, s’assurer que gksu ne soit pas un déguisement de sudo

 $ gksu-properties

=> c’est le gksu installé par défaut de Debian 7 Gnome3, je n’ai rien modifié, je suppose que ça doit être bon :pray:

[quote=“Zbf”]gksu et su c’est différent.
Le 1er te demande le mot de passe utilisateur (comme [mono]sudo[/mono]) pour exécuter une commande avec les droits root.
Le 2nd te demande le mot de passe root pour “devenir” root.

Si tu fais:

sudo touch /fichier_test

ça fonctionne ? Quel mot de passe entres-tu ?[/quote]

=> je n’utilise pas sudo sur mon autre machine mais je ferai le test prochainement, promis! :wink:

POUR RÉSUMER À CE JOUR: JE LE TIENT!!! :115 J’ai (enfin! :118 ) un openbox fonctionnel en user normal. Voici comment j’ai fait pour ceux qui n’y sont pas encore parvenus, sous réserve que ceux qui s’y connaissent bien plus que moi veuillent bien analyser ce que j’ai fait pour voir si je n’ai pas fait de bétises :mrgreen:

-> install de Debian 7.5.0 netinstall amd64 + firmwares ici: http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/amd64/iso-cd/
-> login shell en root

nano /etc/apt/sources.list

-> rajout des catégories ‘contrib’ et ‘non-free’ sur tous les dépots (certains l’ont déjà grâce au CD non-officiel) [Ctrl+o, entrée, Ctrl+x]

apt-get update

apt-get upgrade

apt-get install sudo

adduser MONUSER sudo

visudo

-> rajout de ‘Defaults rootpw’ sous les lignes ‘Defaults xxxxxx’ <- attention c’est une tabulation entre Defaults et la valeur

reboot

-> pour être sûr de la prise en compte des modifications de visudo
-> login shell en MONUSER
$ sudo -i
-> saisie du mot de passe root

apt-get install xorg openbox menu obconf obmenu xterm numlockx

-> +191 paquets téléchargés et 104Mo d’espace disque

mkdir /home/MONUSER/.config

cp -r /etc/xdg/openbox /home/MONUSER/.config/openbox

echo exec openbox-session > /home/MONUSER/.xinitrc

chmod +x /home/MONUSER/.xinitrc

chown -R MONUSER:MONUSER /home/MONUSER

exit

$ startx

Pour faire tout ça je me suis basé sur tous vos bons conseils et un tuto recyclé: http://qweg3.info/minimal-awesome-wm-installation-on-debian-70-wheezy/ car il concerne awesome et non openbox, mais ça marche quand même. D’ailleurs il propose de démarrer automatiquement la session openbox, je vais tenter mais avant je dois dormir un petit peu et attendre vos retours sur mes manips avant de commettre éventuellement d’autres erreurs en plus… :079

#14

[quote=“Zbf”]gksu et su c’est différent.
Le 1er te demande le mot de passe utilisateur (comme [mono]sudo[/mono]) pour exécuter une commande avec les droits root.
Le 2nd te demande le mot de passe root pour “devenir” root.
[/quote]
Dans un fonctionnement logique, il n’y aurait pas de confusion, gksu s’utiliserait pour su et gksudo pour sudo. Or, ces principes qui paraissent logiques ne sont pas aussi nets et tranchés.
gksu est ambivalent, [mono]su[/mono] et [mono]sudo[/mono].
(gksudo : sudo, pas de confusion)
À travers gksu tu peux utiliser [mono]su[/mono] ou [mono]sudo[/mono] sans le savoir.
$ man gksu

[code]
GKSU(1) User Commands GKSU(1)

NAME
gksu - GTK+ frontend for su and sudo

SYNOPSIS
gksu

   gksu [-u <user>] [options] <command>

   gksudo [-u <user>] [options] <command>

DESCRIPTION
This manual page documents briefly gksu and gksudo

   gksu  is a frontend to su and gksudo is a frontend to sudo.  Their primary purpose is to run graphi‐
   cal commands that need root without the need to run an X terminal emulator and using su directly.

   Notice that all the magic is done by the underlying library, libgksu. Also notice that  the  library
   will  decide if it should use su or sudo as backend using the /apps/gksu/sudo-mode gconf key, if you
   call the gksu command. You can force the backend by using  the  gksudo  command,  or  by  using  the
   --sudo-mode and --su-mode options.[/code]

for su and sudo : pour [mono]su[/mono] et [mono]sudo[/mono]
it should use su or sudo as backend using the /apps/gksu/sudo-mode gconf key, if you call the gksu command.
: gksu utilisera [mono]su[/mono] ou [mono]sudo[/mono] sur la base de la clé gconf /apps/gksu/sudo-mode.

[mono]sudo[/mono] : commande gksu ou gksudo, option --sudo-mode
[mono]su[/mono] : commande gksu, option --su-mode

Pour déterminer le comportement de gksu, on peut éditer la clé gconf /apps/gksu/sudo-mode au moyen d’un éditeur gconf ($ gconf-editor) ou s’aider de [mono]$ gksu-properties[/mono]

#15

[quote=“piratebab”]Bonjour,
de mémoire, lorsque tu installes openbox, il ne crée un fichier de conf que pour le compte root.
Il faut que tu recopies le rep .openbox dans le /home de l’utilisateur courant, en changeant évidement l’owner et le groupe.[/quote]

j’installe openbox depuis Lenny et openbox est bien configuré avec l’utilisateur standard à chaque fois

je coche au moins les paquets de bases ou standards dans tasksel (je ne sais plus le nom exacte c’est celui tout en bas) il y a peut être une subtilité ?
ensuitej’active les dépôts non-free:

#aptitude install xorg mesa-utils alsa alsa-utils aptitude install gdm openbox obconf obmenu tint2 nitrogen thunar thunar-volman lxappearance
enfin bref
j’utilise gdm car c’est bien pratique pour éteindre et reboot avec openbox grâce à gdm-control
je ne me souvient pas d’avoir eu de probleme particulier à l’install d’openbox (a part les probs de driver de cg mais ça ne fonctionnait ni en root ni avec l’user)

#16

J’avais déjà tenté l’aventure de la debian superlight avec openbox et j’en suis revenu car quand on paramètre l’environnement pour un certain confort (un peu à la crunchbang…) on s’aperçoit qu’un xfce dépouillé consomme à peine plus de ram tout en étant plus cosy.
Par contre pas de sudo que du vrai root inside…

#17

@sinozis,
Je cherche a faire très light, c’est pourquoi je n’ai pas coché “utilitaires usuels du système”. Je cherche aussi à en faire un max à la main quitte à galérer, je n’installe que ce dont j’ai besoin. Je n’explique cependant pas pourquoi ça marche dès l’install chez toi mais pas moi, je manque de connaissances pour ça :slightly_smiling:

@Triangle,
J’ai testé #! Waldorf, c’est pas mal mais pas ce que j’attends de mon système, il y a déjà trop de choses. Quand je dis ultra light dans le titre je peux mettre aussi austère, donc pas de fioritures, que du fonctionnel, c’est le bémol de mon projet. Par compte selon l’avancement je testerai des paquets pour customiser un peu tout ça et même avec pleeeiiiinn de gadgets je pense avoir de meilleures perfs que sous gnome3 que j’ai sous mon autre machine et que tout fonctionne dès le début par compte :smiley: Aussi, les copains plus haut le disent et au moins du point de vue sécurité ils ont raison, ce n’est pas bien du pur root, c’est pourquoi vu mes galères avec su j’ai utilisé sudo mais avec un comportement à la su (demande du pass root au lieu de celui de l’user). J’avais pensé prendre un système et retirer ce dont je n’ai pas besoin (xfce dépouillé que tu évoques) mais je pense passer plus de temps à faire ça que de construire un système en partant d’une base minimaliste. Ta remarque est cependant pertinente du point de vue ressources matérielles, merci! :wink:

#18

il faudrait que je reprenne mes notes d’intall d’openbox, mais le fichier de config n’est créé automatiquement que pour le user que tu définis à l’install. Si tuajoute manuellement un autre user, il faut le mettre le fichier de config d’openbox).
Pour mes debian light, je fais comme toi. Install minimal, puis ajout petit à petit des paquets nécessaires.
Et pas de sudo chez moi …

#19

Sinon la commande qui tue le mythe ubuntu : $sudo su :075

#20

Dans la même veine , hack à deux centimes pour pouvoir user de su (root) en ubuntu.

Il suffirait de sortir root du placard :

$ sudo bash

passwd

et voilà une ubuntu déniaisée qui a vu [strike]le loup[/strike] root …