====== Trucs divers ====== ===== hack de mémoire ===== Comme vous ne le savez peut être pas, la mémoire (RAM) n'est pas forcément effacé aprés l'extinction.... On en parle là: http://citp.princeton.edu/memory/exp/ En passant, on apprend comment voir le texte de la mémoire... # strings /dev/mem | less Le plus marrant restant une technique pour recuperer l'etat de la mémoire au redemarrage: http://www.mcgrewsecurity.com/tools/msramdmp/ ===== USB bootable ===== ==== a la main ==== Rendre [[http://www.remote-exploit.org/backtrack_download.html|backtrack3]] bootable... Dans cette exemple, l'iso téléchargé est destiné à être bootable sur USB (... et je n'ai pas trouvé plus simple que ce qui suit... === format === Préparer la clé USB, on suppose qu'elle est en **''/dev/sdd''** : # fdisk /dev/sdd Effacer toutes les partitions et en creer une en FAT32 (type "b") et bootable. Retour sur le shell: # mkfs.vfat /dev/sdd1 Mounter, (aprés avoir créé **''/mnt/sdd1''**) : # mount /dev/sdd1 /mnt/sdd1 === mounter iso === Mounter l'iso qu'on a téléchargé et qu'on veut rendre bootable: # mount -o loop ./bt3final_usb.iso /mnt/iso === Copier === # cp -R /mnt/iso/BT3 /mnt/sdd1/ # cp -R /mnt/iso/boot /mnt/sdd1/ === bootinst.sh === # cd /mnt/sdd1/boot | :!: Il faut vraiment être sur la clé mounté. | # ./bootinst.sh === fin === # cd / # umount /mnt/sdd1 Et voila. ==== unetbootin ==== Il existe un ELF32 pour faire cela... ELF32 ? à executer en root en plus... ===== forcer reboot ===== Lien: *http://www.debian-administration.org/articles/457 *http://blog.air4web.com/linux-force-reboot.html Comme j'ai un accès partiel via **''ssh''**, je peus lancer quelques commandes, mais guère plus. Verifions que ce qu'on veut faire est possible: $ ssh root@ "cat /proc/sys/kernel/sysrq" Password: 1 A priori, oui. Mais si c'est necessaire: $ ssh root@ "echo 1 > /proc/sys/kernel/sysrq" Password: Et pour rebooter: $ ssh root@ "echo b > /proc/sysrq-trigger" Password: Et pan! Sinon, il y a aussi: pour eteindre, pour sync les disks, etc... ===== Sniffer ===== Installer **dsniff** pour sniffer les passes en clair: FTP, www, etc... ===== QuickTime sous Linux ===== Il suffit d'acheter **CrossOver Office Professional** et de l'installer. Ce logiciel permet d'installer quelques applications Windoz sous Linux, un peu comme **Wine** mais en plus fort. Le plus fort, c'est que le plugin QuickTime fonctionne dans Mozilla ! ===== Envoyer un mail d'un shell ===== Installer **mailx** # apt-get install mailx Puis envoyer un mail a **root** $ mail -s "mon sujet" root@localhost Taper le message et terminer par [Control]+[D] sur une ligne vide ^D Cc: Et c'est envoyé. Ajouter **-v** pour voir ce qui ne marche pas. Editer **/etc/aliases** pour avoir une ligne contenant: root: tjaouen@le_site.fr ===== Forcer un "fsck" au prochain "boot" : ===== Lien: http://blog.gnusquad.org/2008/12/19/forcer-la-verification-des-partitions-au-demarrage/ Il suffit de faire: # touch /forcefsck Mais on peut aussi faire: # shutdown -r -F now A l'inverse, on peut desactiver le "fsck" en faisant: # touch /fastboot ou # shutdown -r -f now Sinon, on peut definitivement régler le "fsck" en usant de la commande "tune2fs". (voir "man") ===== Desactiver le bouton "power off" ===== Lien: http://linux.derkeiler.com/Mailing-Lists/Debian/2005-06/1917.html Dans: **''/etc/acpi''** modifier le fichier **''powerbtn.sh''**, pour avoir, en debut: #!/bin/sh # /etc/acpi/powerbtn.sh # Initiates a shutdown when the power putton has been # pressed. # TJ ---------------- echo "Power button pressed... But disabled !" | wall echo "Power button pressed... But disabled !" | mail -s "$0" root@localhost exit 0 # ------------------- ... snip ... Ensuite, on aura juste un avertissement de la sorte: Broadcast Message from root@warez-unvs (somewhere) at 11:89 ... Power button pressed... But disabled ! ===== Installer un noyau 2.6 sur 2.4 ===== C'est trés facile, faut pas se tromper. ==== Remplacer **lilo** par **grub** ==== Oui, je préfère **grub**, mais surtout, une première tentative avec **lilo** ne m'a jamais permit de choisir le noyau au boot... grrrr... # apt-get install grub # grub-install /dev/hda # update-grub # apt-get remove lilo --purge Le problème, si on oublie **update-grub**, on demarre dans un shell bash-minimal et c'est embettant. Ensuite, a chaque mise à jour avec un nouveau noyau, il faut faire: **update-grub** qui créé ou met a jour le fichier **/boot/grub/menu.lst** . Et oui, la mise à jour n'est plus automatique, c'est un mistère. **UPDATE** En fait, il suffit de corriger le problème suivant pour le **update-grub** soit fait automatiquement. Verifier qu'on a dans **/etc/kernel-img.conf** # Do not create symbolic links in / do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = no **postinst_hook = /usr/sbin/update-grub** **postrm_hook = /usr/sbin/update-grub** === Ca boot plus === En cas de pépin, si le boot ne fonctionne plus, demarrer avec un **live cd** comme **kubuntu** et faire ainsi: $ sudo mkdir /mnt/sys $ sudo mount /dev/hda1 /mnt/sys $ sudo chroot /mnt/sys $ sudo grub-install /dev/hda $ sudo update-grub $ sudo reboot Ca devrait reparer grub... ==== Upgrade ==== Aprés un rapide reboot avec grub: D'abord raffraichir sa configuration: # apt-get update # apt-get upgrade # apt-get dist-upgrade Truc: Simuler une installation # apt-get -s install le_paquet Voir ce que va faire **install** # apt-get -s -u install le_paquet Il faut savoir que **udev** et **hotplug** sont incompatible entre eux, et que le noyau 2.6 préfère **udev**... donc. # apt-get install udev Et si necessaire ( si **dpkg -l | grep hotplug** retourne **hotplug...** ) # apt-get remove hotplug --purge Et enfin: # apt-get install kernel-image-2.6-686 Et non pas **linux-image...** qui m'a foutu le bordel... Et ne pas oublier: # update-grub Parce que mon install de **grub** a partiellement foiré et que c'est necessaire pour mettre a jour le **menu.lst**... Un reboot, et on devrait pouvoir booter avec le nouveau noyau. Et encore enfin: # apt-get upgrade # apt-get dist-upgrade Et oui, encore et encore. ===== Stress et test de linux ===== Lien: [[http://www.keylabs.com/linux/linux_tools.html|linux tools]] Pour le disk: # apt-get install bonnie++ Et puis: $ bonnie ou /usr/sbin/bonnie Pour le cpu: # apt-get install cpuburn Et puis, pour un Pentium 5: $ burnP5 Plus general: # apt-get install stress Exemple: $ stress --cpu 8 --io 4 --vm 2 --vm-bytes 128M --timeout 2h --hdd 1 ou sur une bécanne plus grosse: $ stress --cpu 16 --io 8 --vm 8 --vm-bytes 1G --timeout 1h --hdd 8 --hdd-bytes 5G ===== Vi ou VIM ===== ==== Imprimer a partir de VI ==== Il suffit de taper: :hardcopy Et hop ==== Definir l'imprimante par defaut ==== Quand on a perdu le mot de passe d'acces a http://localhost:631 , il faut editer **/etc/cups/printers.conf** et renommer la section **** en **** . ===== Configurer une imprimante ===== ==== Avec cups ==== Installer les ppd qui vont bien (notamment pour HP Laserjet) # apt-get install linuxprinting.org-ppds Et puis: http://localhost:631 ==== Sans cups ==== En gros: Il faut que le daemon "lpd" existe... ps aux | grep lpd Sinon, faudra faire quelque chose: moi, j'ai fait: # apt-get install lpr Mais ce n'est pas "normal" de faire ainsi. Pour déclarer l'imprimante, il faut editer le fichier /etc/printcap Et avoir dedans ceci: lp|Remote printer entry: :lp=: :rm=192.168.1.113: :sd=/var/spool/lpd/remote: :mx#0: :sh: Où, 192.168.1.113 est l'adresse de l'imprimante... Ensuite: # /etc/init.d/lpd restart # lpq ceci permet d'interroger l'imprimante (ou un truc du genre) Sous KDE, en lancant "kedit", on peut faire un simple test d'impression. ===== (k)unbutu ===== ==== Root come back ==== Pour qu'on retrouve le **root**, il faut faire: $ sudo passwd root Puis entrer le mot de passe de **root**. Mais aprés, j'ai des trucs bizarre comme ça: # gvim /etc/hosts Xlib: connection to ":0.0" refused by server Xlib: No protocol specified **root** ne serait pas autorisé a ouvrir une session X ... ou un truc du genre... Donc je fais avec **sudo**: $ sudo xhost +local:root non-network local connections being added to access control list Et ensuite, ca fonctionne, enfin, sous **root** Mais pour survivre au boot:\\ Lien: http://www.linuxquestions.org/questions/showthread.php?threadid=331779 Ajouter dans **/root/.bashrc** : export XAUTHORITY=/home//.Xauthority ===== rsync ===== Avant propos: [[http://kaakool.free.fr/wiki/pmwiki.php?n=Informatique.Trucs#SSH|SSH]] peut etre aussi une bonne introduction... **"rsync"** optimise le mirroring en ne mettant à jour uniquement ce qui a changé... \\ Pas besoin de 'daemon' ou de bidouiller la configuration ("rsyncd.conf" n'a pas été nécessaire dans mon cas). Il suffit que "sshd" existe et tout va (essentiellement) passer par lui. ==== Faire un "rsync" d'une source vers une destination par le réseau: (Exemple) ==== $ rsync -a -e ssh user@host:~/source/ ~/dest Ca aura pour effet de: - De s'authentifier en tant que "user" sur la machine (distante) nommé "host". - De transferer (intelligement) le contenu de ~/source/ dans le repertoire local ~/dest Si l'on souhaite ajouter des parametres a l'execution de SSH, comme par exemple modifier le port: $ rsync -a -e "ssh -p 10022" ... etc... Et on utilisera le port "10022" ==== Faire un 'backup' avec historique: ==== Le but est d'avoir une copie de sauvegarde de chaque fichier modifié. $ rsync --delete --force --backup --backup-dir=/home/thierry/bak/`date +m-%d` -av data/ backup2 Le repertoire "/home/thierry/bak/*" recueil les fichiers avant modifications (dans un sous répertoire nommé de la date du jour). \\ Le repertoire source est "data/". \\ La destination est "backup2" Attention: le repertoire pour '--backup-dir' est relatif au repetoire de destination... d'où la necessité de definir le repertoire a partir de la racine '/' . ==== rsync et vfat ==== === cas 1 === Lien: http://www.kylev.com/2005/03/29/rsync-and-vfat/ une clé USB en vfat, vers laquelle on fait un ''rsync'' avec des noms bizarres... Monter la clé comme ca: # mount -t vfat -o shortname=mixed,iocharset=utf8 /dev/sde1 /mnt/wd Et puis: # rsync --modify-window=1 -av /data/mp3 /mnt/wd/. === cas 2 === On essaye de copier des fichiers avec des noms curieux sur une partition vfat, mais rsync retourne une erreur du style: ... failed: Invalid argument (22) ... On remount la vfat comme ça: # mount -o remount,codepage=cp850,iocharset=iso8859-1 /mnt/partition Et voila. ==== Mirror disk ==== Faire une copie complete d'un disk a un autre avec **''rsync''** . Pour une partition virtuelle, genre Xen, c'est parfait et bien plus rapide que **''dd''** . Pour cela faire: # rsync -ax --delete --force / Exemple: # rsync -ax --delete --force /mnt/disk-source/ /mnt/disk-dest Si vous faites un transfert reseau sur une partition qui n'est pas destiné à l'hôte, alors ajouter **''--numeric-ids''** si vous voulez pas que les "uid/gid" sont convertie. ==== numeric-ids ==== J'ai découvert sur le trop-tard que ''rsync'' fait une conversion par "nom" d'identifiant, lorsque les transferts s'effectuent entre 2 systèmes differents, avec, a priori, des utilisateurs identiques mais au uid / gid potentiellement differents. Ainsi: L' ''uid'' 1000 associé à ''thierry'', pourrait devenir 1001 ... parce que ''thierry'' y existe déjà sur ce système avec cette ''uid''. Cool ? Non, pas trop. Pour désactiver ce truc, ajouter l'option : **''--numeric-ids''** ===== ntpdate ===== C'est donc le machin qui permet de garder les machines a l'heure. C'est bien d'utiliser **ntpdate** pour cela. Installer # apt-get install ntpdate Forcer une mise a jour maintenant # /etc/init.d/ntpdate start Mise a jour toute les nuits vers 3h18 # crontab -e Et ecrire dedans le **crontab** 18 3 * * * /etc/init.d/ntpdate start >/dev/null 2>&1 Pourquoi ne pas appeller directement **/usr/bin/ntpdate** **?** Parce que **/etc/init.d/ntpdate** est déjà configuré pour être //croné// Pas besoin de configurer de serveur 'ntp'. Sinon, il y a: ntp.tuxfamily.net ntp.dedibox.fr ===== wget ===== Recupérer une page et tout ce qui permet de l'afficher (en gros: les images aussi) wget -p url Ca ressemble à **wget -r -l0 ...** mais en mieux. ==== robots.txt ==== Si ca ne fonctionne pas comme voulu, c'est peut etre a cause du '/robots.txt':\\ **''wget''** respecte ''/robots.txt'', pour desactiver ça, faire simplement: wget -e robots=off url... ==== user-agent ==== Quand la signature du browser pose un problème, ajouter: -U "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)" ===== ARJ ===== # apt-get update # apt-get install arj Pour decompresser une archive qui a été compresser dans un environnement Windoz: arj x le_fichier.ARJ **-hf2** -y ===== Apt ===== ==== Comment que quoi "apt-get update" me retourne une "GPG error"... ==== Sans trop comprendre, ceci fonctionne (en 2006): # wget http://ftp-master.debian.org/ziyi_key_2006.asc # gpg --no-default-keyring --keyring /etc/apt/trusted.gpg --import ziyi_key_2006.asc Et hop: "apt-get update" et compagnie, ne m'enmerde plus avec les 'gpg error' ==== NO_PUBKEY A70DAF536070D3A1 ==== Lorsqu'on a une erreur comme cela, il faut installer la cle publique: # gpg --keyserver wwwkeys.eu.pgp.net --recv-keys A70DAF536070D3A1 Qu'on peut alors extraire et voir comme cela: # gpg --armor --export A70DAF536070D3A1 Et surtout, qu'on va ajoute a la liste des cles de **apt**: # gpg --armor --export A70DAF536070D3A1 | apt-key add - Et voila. ===== SSH ===== ==== PasswordAuthentication No ==== Lien: http://geekosphere.org/43/safer-ssh-passwordauthentication-no/ === vite dit === Forcer l'usage de clés RSA. (voir plus loin) PasswordAuthentication no PubkeyAuthentication yes ( "PubkeyAuthentication" est a "yes" par defaut) === fine tune === Mais si on veut autoriser certains users , dans des conditions bien précises: PasswordAuthentication no Match user thierry , address 127.0.0.0/8 PasswordAuthentication yes Match user thierry , address 192.168.166.0/24 PasswordAuthentication yes Match user root , address 127.0.0.0/8 PasswordAuthentication yes ( verifier "," ) ==== ipv6 ==== === disable === Lien: http://ubuntu-tutorials.com/2008/01/12/disabling-ssh-connections-on-ipv6/ Dans **''/etc/ssh/sshd_config''** : ... # What ports, IPs and protocols we listen for Port 22 # Use these options to restrict which interfaces/protocols sshd will bind to #ListenAddress :: #ListenAddress 0.0.0.0 # TJ --------- # ipv4 only ListenAddress 0.0.0.0 # ------------ ... et hop: # /etc/init.d/ssh restart ==== Securité ==== Editer **''/etc/ssh/sshd_config''** et avoir: PermitRootLogin no et AllowUsers thierry truc machin bidule Afin de n'autoriser que certains utilisateurs a se logguer... ==== Les clés ==== Tous ce passe globalement dans "~/.ssh" Sous le user en question: Si on veut que ça fonctionne aussi avec SSH1, creer les clés dsa: $ ssh-keygen -t dsa Sinon, il est suffisant de faire les clés RSA: $ ssh-keygen -t rsa On a alors un repertoire comme ça: -rw------- 1 thierry thierry 1675 2006-08-16 14:26 id_rsa -rw-r--r-- 1 thierry thierry 397 2006-08-16 14:26 id_rsa.pub -rw-r--r-- 1 thierry thierry 3866 2006-08-16 14:13 known_hosts C'est **id_rsa.pub** la clé publique !!! ;-) ==== Accès sans mot de passe ==== Il faut transferer la clé publique sur la machine distante (en fait, sur celle qu'on voudrait se connecter, sans une demande de mot de passe). $ scp ~/.ssh/id_rsa.pub thierry@la_machine:/home/thierry/tmp/. Puis, on va sur **la_machine** (on entre encore le mot de passe), et on ajoute le contenu de **id_rsa.pub** dans ~/.ssh/authorized_keys $ cat ~/tmp/id_rsa.pub >> ~/.ssh/authorized_keys Et voila, la prochaine demande d'authentification ne sera pas faite "à la main", mais par le biais de la clé publique. === Restriction === Liens: http://www.idris.fr/data/faq/ssh_keys.html On peut restreindre les actions permises lorsqu'une session est ouverte par le biais du fichier ''authorized_keys''. $ man sshd Vous fera decouvrir "from" ou "command" ou "no-pty" et bien d'autres options. Par exemple, ajouter (en début de ligne) : from="localhost" ... Ce qui aura pour effet de restreindre cette clé juste a un usage via "127.0.0.1" . ==== Plusieurs serveurs ssh derrières une IP ==== Pour ajouter dans **known_hosts** pour outrepasser le controle. ssh-keyscan -H -t rsa,dsa -p 5322 ip_ou_nom_du_serveur >> ~/.ssh/known_hosts **5322** est le port du serveur. Je ne suis pas certain de l'usage de **-H**, mais ca fonctionne sous kubuntu. la signature (ou la clé publique?) est inscrite dans **known_hosts**. ==== Tunnel sécurisé avec SSH ==== === La syntaxe === Le but est de creer un **tunnel sécurisé**, par SSH, entre un client et un serveur. Le client étant celui qui a l'initiative de la connexion, et le serveur étant celui qui attend la connexion. client@machine$ ssh -L IN_CLIENT:localhost:OUT_SERVER IP | IN_CLIENT | port ouvert sur la machine du client par SSH | | LOCALHOST | On ne peut que se connecter en local | | OUT_SERVER | port du serveur sur lequelle SSH va faire aboutir la connexion | \\ Exemple en sécurisant une connexion par VNC: client@machine$ ssh -L 5950:localhost:5901 shampoo.tj.fr Aprés la demande du mot de passe, et toujours sur le client: on peut demarrer **vncviewer** et entrer l'adresse: **localhost::5950** | CLIENT | LE RESTE DU MONDE | SERVEUR | | localhost:5950 | tunnel securisé par SSH (port 22) | localhost:5901 | | ===> | ===> | ===> | La commande ci-dessus ouvre aussi un accès au commande SSH, ce qui est fort pratique lorsqu'on veut fermer le tunnel, il suffit de fermer la session SSH. === Tunnel sans session d'ouverte === Mais on peut aussi ouvrir un tunnel simplement, sans vouloir d'accès à la session SSH. Faire ainsi: ssh -f -N -L IN_CLIENT:localhost:OUT_SERVER IP Cela **fork** le terminal dans le '/dev/null'... Waouh! ... Et comment on ferme le tunnel maintenant ? $ ps aux | grep ssh thierry 6472 0.0 0.1 6064 1220 ? Ss 23:25 0:00 ssh -f -N -L 5950:localhost:5901 21.2.3.1 $ kill 6472 === Tunnel via SSH par VNC === $ vncviewer localhost:1 -via IP_du_serveur C'est encore mieux quand on peut se connecter a n'importe quel machine du reseau ! $ vncviewer IP_LOCAL::5900 -via IP_du_serveur ==== sshfs ==== Interessant quant ça marche: mounter un accès via ssh Liens: [[http://ubuntu.wordpress.com/2005/10/28/how-to-mount-a-remote-ssh-filesystem-using-sshfs/|How to mount a remote ssh]]http://fuse.sourceforge.net/sshfs.html Cas pratique: le site **artigo** Je monte un repertoire via ssh, accessible par ftp: # sshfs loulou@IP:/local1/admin/apache2/www/artigo /home/artigo/ftproot/www -o rw,allow_other Et pour demonter: # fusermount -u ./www ==== SSH et X11 ==== Comment voir sur son poste (client) des applications X s'executant sur un serveur distant... simple: c'est le **X11 Forwarding** Sur le "serveur" (celui qui va executer les applications X): editer le fichier **/etc/ssh/sshd_config** et apporter la modification suivante: X11Forwarding yes Si necessaire, ce qui n'a pas ete le cas sur mon kubuntu par exemple (mais sur une debian si). Et ne pas oublier (si la modification a été faite): # /etc/init.d/ssh restart Retour sur le "client" (celui qui va voir les applications X11): ouvrir un terminal sous X et taper: $ ssh -X adresse_du_serveur Une fois authentifier et qu'on a acces au shell du "serveur", taper (par exemple): $ mozilla-thunderbird Et hop (enfin, aprés quelques longues secondes ou minutes): on voit son lecteur de mail. Exemple plus etonnant: $ /home/thierry/.cxoffice/win98/desktopdata/cxmenu/Desktop/Internet+Explorer Ce qui demarre un "Internet Explorer" de Windoz avec l'emulateur "wine" (et "CrossOver") et l'affiche sur mon poste client... c'est magnifique. Ce qui est amusant, c'est que j'ai fait mes tests en passant par un tunnel VPN... ssh+VPN, sa rame un peu mais c'est super crypté :-) On peut voir que la connexion X est redigiré, car sur le serveur on voit ça: $ echo $DISPLAY localhost:10.0 ===== Samba et Windows ===== ==== Methode 1 : Pour ouvrir un partage Windows ==== Le but, c'est de permettre à un **user** d'acceder a un partage Windows, sans qu'il soit trop necessaire de farfouiller le systeme et de mettre a nu ces droits. D'abord, passer en **root** et autoriser l'usage de **smbmnt** et **smbumount** par un user. # chmod u+s /usr/bin/smbmnt # chmod u+s /usr/bin/smbumount ATTENTION: ne pas faire ** +s ** sur **smbmount** mais bien sur **smbmnt** uniquement. (Sinon on a une erreur de la forme: //libsmb based programs must *NOT* be setuid root// ) Ensuite, on revient en **user** et on peut simplement utiliser **smbmount** et 'smbumount''': J'ai 2 disques en partage: C et D $ mkdir ~/mnt/172.16.0.35/C $ mkdir ~/mnt/172.16.0.35/D Et puis je **mount** (j'ai fait un 'bash' pour ça) cat 172.16.0.35_mount.sh #!/bin/bash IP=172.16.0.35 USERNAME=thierry PASSWORD=mon_mot_de_passe # --------------------------- smbmount //$IP/C$ ~/mnt/$IP/C -o username=$USERNAME,password=$PASSWORD smbmount //$IP/D$ ~/mnt/$IP/D -o username=$USERNAME,password=$PASSWORD (Le **$** ne semble pas nécessaire... donc eviter si possible) Et pour **umount**, j'ai un autre 'batch': cat 172.16.0.35_umount.sh #!/bin/bash IP=172.16.0.35 # --------------------------- smbumount ~/mnt/$IP/C smbumount ~/mnt/$IP/D Cette methode a ma preference car l'acces aux fichiers partagés est complement intégré a l'environnement. (Par exemple, on peut editer/modifier/effacer des fichiers sans contrainte) ==== Methode 2 : Pour ouvrir un partage Windows ==== (Je prefere la methode 1) Editer **/etc/fstab** (en **root**) # vi /etc/fstab puis //IP/DRIVE_LETTER$ /home/thierry/mnt/IP/DRIVE_LETTER smbfs rw,user,noauto,username=thierry,password=le_mot_de_passe 0 0 (virer le **password** si on souhaite qu'il soit demander a chaque **mount**) Toujours en **root**, autoriser **smbmnt** a fonctionner en **root** pour un **user** (ce qui permettra au **user** d'activer le partage) # chmod u+s /usr/bin/smbmnt Et accessoirement, autoriser un **user** a **umounter**: # chmod u+s /usr/bin/smbumount Créer un répertoire dans sa home $ mkdir /home/thierry/mnt/IP/DRIVE_LETTER Puis **mounter** comme ceci $ mount ~/mnt/IP/DRIVE_LETTER