JJD a écrit 516 commentaires

Salut,

Sous un Unix (come Linux), il faut avoir les droits root pour pouvoir ouvrir des ports <1024.
Chez toi, avec ta commande hts, tu ouvres le port 80, ce qui fonctionne parce que tu dois lancer cette commande en root.

En revanche, à ton université, tu essaies d'ouvrir le port 22 sur le serveur où tu es connecté, ce que tu n'as pas le droit de faire (d'autant que ce port est certainement déjà utilisé par le serveur SSH local).

La solution est de préciser un autre port XXXX au dessus de 1024 (et non déjà utilisé sur ton serveur !)
Ensuite tu te connectes chez toi en tapant :
ssh -p XXXX user@localhost.

Si tu veux mon avis, tu devrais également utiliser un port différent pour la partie serveur chez toi (hts). Ainsi hts serait lancé avec les droits d'un simple utilsateur, plutôt qu'avec les droits root. Il y a de grandes chances que le proxy de ton université autorise aussi le port 8080 (voire d'autres, à essayer ...)

Tout ça marche plutôt bien (je le fais à mon taf), même si c'est un peu plus lent qu'une connexion directe.

A+
JJED

Le meilleur moyen de fixer les droits d'accès sur les partitions est effectivement d'utiliser les bonnes options de mount. Le plus simple est d'aller mettre ces permissions dans /etc/fstab. On peut en particulier préciser les options :
uid=
gid=
umask=
Pour attribuer des droits à un utilisateur ou un groupe particulier.

exemple :

/dev/hda1    /mnt/windows   ntfs     defaults,uid=0,gid=1000,umask=227   0    0 

va autoriser les membre du groupe 1000 (voir /etc/group), et uniquement eux, à accéder aux fichier de la partition

En revanche, je ne vois aucun moyen d'autoriser l'accès en lecture à certains fichiers/répertoire et de le refuser pour d'autres sur la même partition [il est déconseillé de monter une partition NTFS en écriture pour ne pas la corompre]

Si quelqu'un a une solution ...

Tu peux essayer la méthode de configuration automatique pour démarrer

XFree86 -configure

Ça devrait te donner une configuration - à peu près - utilisable. Après, system-config-display devrait fonctionner.

umask permet effectivement de définir, dans leur ensemble, les droits des fichiers créés.
Ainsi, après la commande 'umask 0007', tous les fichiers seront créés avec les les droits de lecture et écriture pour l'utilisateur et son groupe et sans aucun droit pour les autres.
On peut aussi utiliser la commande umask avec le format symbolique (comme chmod) ainsi :
umask ug=rwx,o-rwx

Je ne connais pas de moyen de spécifier ce masque de droit par répertoire. Si quelqu'un a une méthode je suis aussi preneur (on peut se simplifier la tache avec des alias qui enchainent les commandes cd + umaski, mais ce n'est pas vraiment satisfaisant)

En revanche, il est possible de jouer sur les groupes pour partager certains droits avec des utilisateurs particuliers :
Tu crées un groupe 'projet' dans le quel tu mets un certain nombre d'utilisateurs, puis tu crées un répertoire Projet avec les droits 2770 (mkdir -m 2770 Projet ; chgrp projet Projet). Ainsi tous les fichiers créés dans le répertoire Projet appartiendront au groupe projet (avec les droits de relatifs au umask courant).

En espérant avoir pu un peu t'aider ...

Essaie avec ça :

find /mon_rep -mtime -1 -type f | awk '{print "\042" $0 "\042" }'  | xargs tar -cpvszf mon_fichier.tar.gz

En espérant avoir pu t'aider.

Le problème est connu, mais non corrigé : voir
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=224067(...)

Dans /var/log/auth.log tu devrais voir apparaître :
/dev/tty3: already in use
à plusieurs reprises.

A suivre ...

Si $arg contient l'argument à tester,

${arg%.*}

renvoie la chaîne $arg sans la dernière extension (ou toute la chaîne si'il n'y a pas de point)

${arg#*.}

renvoie $arg en supprimant tout ce qui précède le premier point (ou toute la chaîne s'il n'y a pas de point).

Quelque chose comme ça devrait fonctionner :

if [ $arg != ${arg%.*}.${arg#*.} ]

then

    echo "Mauvais argument  : $arg"

    exit 1

fi

Un serveur VNC te permettra de rendre accessible, sur un client VNC, une session X différente de celle que tu as en local. C'est une solution facile à mettre en œuvre, mais il faudra penser à lancer, dans la session X créée, tout ce qu'il faut pour avoir un environnement complet (WindowManager, Session KDE ou Gnome, ...)
Si tu veux exporter, vers un client VNC, le DISPLAY local, il te faudra un serveur dédié, comme x0rfbserver (http://www.hexonet.de/software/rfb(...)), krfb (sous KDE), vino (GNOME) ou d'autres fonctionnant sur le même principe (il doit exister des paquetages pour la plupart des distributions).
Un fois le serveur lancé, on accède au desktop à partir d'un client VNC disponible sur la plupart des plateformes (Linux, Windows, Palm, ...).

Il est également possible (comme avec les versions précédentes) d'aller dans 'fichier->Ouvrir un emplacement...' et de taper l'URL à atteindre sous la forme ftp://serveur(...) (accès anonyme) ou ftp://user:password@serveur.(...)
En revanche, le fichier .netrc ne semble pas pris en compte et une URL du type ftp://user@serveur(...) ne fonctionne pas (se serait bien d'avoir une popup demandant le mot de passe)

www.lmet.com : libraire spécialisé en informatique sur Paris.

Je pense qu'ils font aussi de la vente par correspondance.

On peut réellement agrandir un FS ext3 SANS faire un umount avant ?

Explique-moi comment tu fais, parce que j'ai dû rater un épisode : tout ce que j'ai trouvé pour agrandir ce type de FS c'est resize2fs, mais il m'a bien semblé qu'il faut démonter la partition, ce qui est génant, par exemple, sur /var puisque ça oblige à arrêter la plupart des applis.

Bonjour à tous,

J'ai longtemps utilisé ext2 (c'est tout ce qui existait) puis ext3 (ça me semblait la suite logique pour passer à un FS journalisé).
Il y a quelques semaines, j'ai basculé toutes les FS à l'exception de / sous reiserfs avec du lvm pour profiter du redimensionnement (ou au moins agrandissement) des partitions et des systèmes de fichiers sans avoir à les 'unmounter' (ce qui n'est pas possible avec ext2/ext3).
Je n'ai pas fait de tests pour vérifier un différence dans les performances, mais je n'ai pas constaté de réel changement à ce niveau.

Je pense que d'autres FS permettent ce genre de choses (jfs certainement, peut-être xfs ou d'autres) : je suis preneur de retout d'info à ce sujet.

A+
JJD

Bonjour à tous,

Il existe egalement un daemon, bootlogd, qui sert justement à récupérer tous les messages pendant le boot.
En pratique, bootlogd doit être le premier daemon lancé au boot et doit être arrêté à la fin. Il se charge d'intercepter toutes les écritures sur la console pour les écrire dans un fichier de log (/var/log/boot).
Je pense qu'il doit être disponible avec le paquet SysVinit.
C'est ce que j'ai trouvé de plus pratique pour pouvoir relire tous les messages au boot (mais je suis sous Debian ;-) )

Tu peux peut-être rajouter l'option 'noauto' dans fstab (et éventuellement 'user') et ne monter les disques concernés que lorsque tu en as besoin

J'ai eu la même chose avec le noyau 2.6.0 sur une Debian SID (utilisation d'une image initrd, avec -tous- les pilotes en module.
Le problème venait d'un initrd trop gros. C'est passé en rajoutant 'ramdisk=4180' dans la section correspondante de /etl/lilo.conf (voir les messages qui précèdent le Kernel panic).
Apparemment, ce problème est corrigé chez Debian avec la version 2.6.0-2 du noyau 2.6.0.

A+

Il doit rester la possibilité pour les fabricants de support (clés USB, disquettes, cartes mémoires, ...) de fournir ces support non formatés.
Un coup de mkdosfs et c'est réglé.
Sous Windows, un clic droit et on formate.
Il me semble que tous les appareils (caméra, appareils photos,lecteurs MP3) ont également une option de formatage dans leurs menus.