Souhaitant installer un macMINI G4 en tant que serveur rudimentaire,
j'ai procédé à sa configuration et à la configuration de la LiveBox en
conséquence (routage des ports 80, 21, 3283, 5900 vers le macMINI placé
en IP fixe). J'ai aussi activé un service DynDns pour "voir" mon MINI de
l'extérieur. Les ports 3283 et 5900 sont ouverts pour Remote Desktop (on
voit son problème après).
1/ pour le serveur WEB, ça marche, je vois aussi bien la page générique
Apache que les pages génériques des utilisateurs. Le dyndns marche, le
routage de ports aussi.
2/ pour le FTP ça bloque, aussi bien pour les users normaux que pour les
users de PureFTPD. Le blocage est clairement dû au FireWall de Mac OS X
puisque quand on le désactive ça marche, et quand on l'active ça ne
passe plus, avec tentative de passage en mode actif, puis re-blocage
donnant le log suivant :
---------------------
257 "/Users/admin" is your current location
TYPE A
200 TYPE is now ASCII
PASV
227 Entering Passive Mode (81,51,30,2,40,185)
ABOR
500 ?
PORT 192,168,1,201,214,12
200 PORT command successful
LIST
Active mode connection blocked by OS X firewall, port 54796
ABOR
ftp_list: -30031 (state == GETTING_LIST)
QUIT
send_cmd():con_conn->Putline() returns -3208
---------------------
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys)
"Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce
coupe-feu pour qu'il arrête de me contrarier ?
3/ Concernant Remote Desktop 3.1 le problème est le suivant : ledit
MacMINI avait une install du *serveur* ARD et j'ai souhaité ne plus le
voir qu'en "client". J'ai désinstallé proprement ARD en suivant la
procédure décrite dans le mode d'emploi :
---------------------
Pour supprimer le logiciel d'administration :
1 Glissez l'application Remote Desktop vers la Corbeille.
2 Videz ensuite la Corbeille.
3 Dans l'application Terminal, supprimez la base de données ARD dans
/var/db/
RemoteManagement/ à l'aide de la commande suivante :
$sudo rm -rf /var/db/RemoteManagement
$ sudo rm /Library/Preferences/com.apple.RemoteDesktop.plist
$ rm ~/Library/Preferences/com.apple.RemoteDesktop.plist
---------------------
...sauf qu'au lieu de supprimer les fichiers en Terminal, je les ai
supprimés avec FileBuddy (qui voit bien les fichiers/dossiers
invisibles), mais ça revient au même.
J'ai créé un paquet d'installation du client 3.1, je l'ai installé et
activé ARD pour les différents comptes et voilà ce qui se passe :
- dans la barre des menus du MINI, l'icône indique bien qu'ARD client
est activé.
- en réseau interne (airport), j'accède sans problème en ARD au MINI
- mais en externe (adresse dyndns), le mac apparaît en "VNC activé"
(icône bleu clair) et non en "disponible" et effectivement je peux y
accéder en VNC (mais pas avec les fonctionnalités ARD et en particulier
pas le glisser-copier entre les bureaux).
- OR (et c'est là que ça devient baroque), sur le MINI, la
fonctionnalité VNC est *décochée* dans les réglages de partage, et
décochée aussi dans les options utilisateurs d'ARD.
- naturellement en principe je sais faire et je contrôle sans problème
plusieurs autres macs "externes". Y a-t-il quelque chose à tenter avant
de réinstaller le système et réimporter les utilisateurs ?
d'avance merci à ceux qui savent.
(léger crosspost dû au fait qu'il s'agit surtout de réglages systèmes,
et FU2 peut-être plus approprié ?)
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys) "Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce coupe-feu pour qu'il arrête de me contrarier ?
Ne pas l'utiliser ou ne pas faire de FTP. ;-(
C'est le réglage "de base" par le TdB "Partage" du firewal Mac OS X 10.4 qui bloque.
Il ne met que: 02070 allow tcp from any to any dst-port 21 in
ce qui est insuffisant... pour faire du FTP.
Le réglage des versions précédentes étaient: 02090 allow tcp from any to any 20-21 in 02100 allow tcp from any 20,21 to any 1024-65535 in
20 pour faire du FTP ACTIV et 1024-65535 pour faire du PASSIV.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Gerald <Gerald@alussinan.org> wrote:
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys)
"Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce
coupe-feu pour qu'il arrête de me contrarier ?
Ne pas l'utiliser ou ne pas faire de FTP. ;-(
C'est le réglage "de base" par le TdB "Partage" du firewal Mac OS X 10.4
qui bloque.
Il ne met que:
02070 allow tcp from any to any dst-port 21 in
ce qui est insuffisant... pour faire du FTP.
Le réglage des versions précédentes étaient:
02090 allow tcp from any to any 20-21 in
02100 allow tcp from any 20,21 to any 1024-65535 in
20 pour faire du FTP ACTIV et 1024-65535 pour faire du PASSIV.
--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:jperrocheau@mac.com
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys) "Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce coupe-feu pour qu'il arrête de me contrarier ?
Ne pas l'utiliser ou ne pas faire de FTP. ;-(
C'est le réglage "de base" par le TdB "Partage" du firewal Mac OS X 10.4 qui bloque.
Il ne met que: 02070 allow tcp from any to any dst-port 21 in
ce qui est insuffisant... pour faire du FTP.
Le réglage des versions précédentes étaient: 02090 allow tcp from any to any 20-21 in 02100 allow tcp from any 20,21 to any 1024-65535 in
20 pour faire du FTP ACTIV et 1024-65535 pour faire du PASSIV.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Gerald
Jacques Perrocheau wrote:
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys) "Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce coupe-feu pour qu'il arrête de me contrarier ?
Ne pas l'utiliser ou ne pas faire de FTP. ;-(
C'est le réglage "de base" par le TdB "Partage" du firewal Mac OS X 10.4 qui bloque.
C'est bien ce qu'il me semblait, mais il y a du nouveau depuis, car le SFTP, lui, marche impeccablement et, franchement, dans ce cas pourquoi s'en priver ! :-) (par contre je ne pige pas du tout la politique d'Apple, qui ne documente pas, en tout cas de façon visible, cette particularité).
Du coup mon problème "d'ARD client qui se transforme en VNC" est en partie résolu puisque je peux accéder sans problème aux fichiers du disque distant et en plus de manière sécurisée par sftp. Reste quand même un mystère double, d'une part parce que ARD marche en local et pas en externe (ça localiserait le problème sur la livebox, un routage de port supplémentaire à faire ?) et d'autre part parce que le décochage de VNC pour l'externe (dans partage et dans les préférences ARD) n'empêche absolument pas l'accès. Bizarre.
-- Gérald
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys)
"Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce
coupe-feu pour qu'il arrête de me contrarier ?
Ne pas l'utiliser ou ne pas faire de FTP. ;-(
C'est le réglage "de base" par le TdB "Partage" du firewal Mac OS X 10.4
qui bloque.
C'est bien ce qu'il me semblait, mais il y a du nouveau depuis, car le
SFTP, lui, marche impeccablement et, franchement, dans ce cas pourquoi
s'en priver ! :-) (par contre je ne pige pas du tout la politique
d'Apple, qui ne documente pas, en tout cas de façon visible, cette
particularité).
Du coup mon problème "d'ARD client qui se transforme en VNC" est en
partie résolu puisque je peux accéder sans problème aux fichiers du
disque distant et en plus de manière sécurisée par sftp. Reste quand
même un mystère double, d'une part parce que ARD marche en local et pas
en externe (ça localiserait le problème sur la livebox, un routage de
port supplémentaire à faire ?) et d'autre part parce que le décochage de
VNC pour l'externe (dans partage et dans les préférences ARD) n'empêche
absolument pas l'accès. Bizarre.
évidemment j'avais bien coché dans préférences/réseau (Airport/Proxys) "Utiliser le mode FTP passif (PASV)". Que peut-on faire au niveau de ce coupe-feu pour qu'il arrête de me contrarier ?
Ne pas l'utiliser ou ne pas faire de FTP. ;-(
C'est le réglage "de base" par le TdB "Partage" du firewal Mac OS X 10.4 qui bloque.
C'est bien ce qu'il me semblait, mais il y a du nouveau depuis, car le SFTP, lui, marche impeccablement et, franchement, dans ce cas pourquoi s'en priver ! :-) (par contre je ne pige pas du tout la politique d'Apple, qui ne documente pas, en tout cas de façon visible, cette particularité).
Du coup mon problème "d'ARD client qui se transforme en VNC" est en partie résolu puisque je peux accéder sans problème aux fichiers du disque distant et en plus de manière sécurisée par sftp. Reste quand même un mystère double, d'une part parce que ARD marche en local et pas en externe (ça localiserait le problème sur la livebox, un routage de port supplémentaire à faire ?) et d'autre part parce que le décochage de VNC pour l'externe (dans partage et dans les préférences ARD) n'empêche absolument pas l'accès. Bizarre.
-- Gérald
jperrocheau
Gerald wrote:
C'est bien ce qu'il me semblait, mais il y a du nouveau depuis, car le SFTP, lui, marche impeccablement et, franchement, dans ce cas pourquoi s'en priver ! :-)
Toutafait.
(par contre je ne pige pas du tout la politique d'Apple, qui ne documente pas, en tout cas de façon visible, cette particularité).
Pour tuer le FTP. ;-)
Du coup mon problème "d'ARD client qui se transforme en VNC" est en partie résolu puisque je peux accéder sans problème aux fichiers du disque distant et en plus de manière sécurisée par sftp. Reste quand même un mystère double, d'une part parce que ARD marche en local et pas en externe (ça localiserait le problème sur la livebox, un routage de port supplémentaire à faire ?) et d'autre part parce que le décochage de VNC pour l'externe (dans partage et dans les préférences ARD) n'empêche absolument pas l'accès. Bizarre.
Là je ne suis pas compétent.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Gerald <Gerald@alussinan.org> wrote:
C'est bien ce qu'il me semblait, mais il y a du nouveau depuis, car le
SFTP, lui, marche impeccablement et, franchement, dans ce cas pourquoi
s'en priver ! :-)
Toutafait.
(par contre je ne pige pas du tout la politique d'Apple, qui ne documente
pas, en tout cas de façon visible, cette particularité).
Pour tuer le FTP. ;-)
Du coup mon problème "d'ARD client qui se transforme en VNC" est en
partie résolu puisque je peux accéder sans problème aux fichiers du
disque distant et en plus de manière sécurisée par sftp. Reste quand
même un mystère double, d'une part parce que ARD marche en local et pas
en externe (ça localiserait le problème sur la livebox, un routage de
port supplémentaire à faire ?) et d'autre part parce que le décochage de
VNC pour l'externe (dans partage et dans les préférences ARD) n'empêche
absolument pas l'accès. Bizarre.
Là je ne suis pas compétent.
--
Jacques PERROCHEAU
________________________________________________________________________
e-mail: mailto:jperrocheau@mac.com
C'est bien ce qu'il me semblait, mais il y a du nouveau depuis, car le SFTP, lui, marche impeccablement et, franchement, dans ce cas pourquoi s'en priver ! :-)
Toutafait.
(par contre je ne pige pas du tout la politique d'Apple, qui ne documente pas, en tout cas de façon visible, cette particularité).
Pour tuer le FTP. ;-)
Du coup mon problème "d'ARD client qui se transforme en VNC" est en partie résolu puisque je peux accéder sans problème aux fichiers du disque distant et en plus de manière sécurisée par sftp. Reste quand même un mystère double, d'une part parce que ARD marche en local et pas en externe (ça localiserait le problème sur la livebox, un routage de port supplémentaire à faire ?) et d'autre part parce que le décochage de VNC pour l'externe (dans partage et dans les préférences ARD) n'empêche absolument pas l'accès. Bizarre.
Là je ne suis pas compétent.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Gerald
Jacques Perrocheau wrote:
Là je ne suis pas compétent.
ça c'est pas souvent ! c'est dire à quel point je suis dans la m. :-)) (pas vrai puisque au final ça marche selon mes besoins. C'est plutôt une curiosité un peu théorique...)
-- Gérald
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
Là je ne suis pas compétent.
ça c'est pas souvent ! c'est dire à quel point je suis dans la m. :-))
(pas vrai puisque au final ça marche selon mes besoins. C'est plutôt une
curiosité un peu théorique...)
ça c'est pas souvent ! c'est dire à quel point je suis dans la m. :-)) (pas vrai puisque au final ça marche selon mes besoins. C'est plutôt une curiosité un peu théorique...)
-- Gérald
laurent.pertois
Gerald wrote:
- mais en externe (adresse dyndns), le mac apparaît en "VNC activé" (icône bleu clair) et non en "disponible" et effectivement je peux y accéder en VNC (mais pas avec les fonctionnalités ARD et en particulier pas le glisser-copier entre les bureaux). - OR (et c'est là que ça devient baroque), sur le MINI, la fonctionnalité VNC est *décochée* dans les réglages de partage, et décochée aussi dans les options utilisateurs d'ARD.
Normal, enfin, si je puis dire.
Quand l'admin Remote Desktop analyse un nouveau client voici la procédure suivie :
- il ping pour trouver le client - connexion sur le port 3283 en UDP - si le précédent ne répond pas il teste le port 5900 en UDP
Est-ce qu'avec ta Livebox tu as bien redirigé ces deux ports en UDP et TCP et pas en TCP seulement ?
Même si tout semble se faire uniquement en UDP, il faut bien TCP et UDP pour Remote Desktop.
De plus désinstaller l'admin RD n'est pas nécessaire, tu peux très bien prendre le contrôle d'un poste qui a ce dernier installé. Par défaut, quand il est lancé, tu ne peux pas contrôler, mais ça se modifie dans les préférences Sécurité (un truc, en français, du genre "Autoriser le contrôle de cet ordinateur quand cette application est lancée").
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Gerald <Gerald@alussinan.org> wrote:
- mais en externe (adresse dyndns), le mac apparaît en "VNC activé"
(icône bleu clair) et non en "disponible" et effectivement je peux y
accéder en VNC (mais pas avec les fonctionnalités ARD et en particulier
pas le glisser-copier entre les bureaux).
- OR (et c'est là que ça devient baroque), sur le MINI, la
fonctionnalité VNC est *décochée* dans les réglages de partage, et
décochée aussi dans les options utilisateurs d'ARD.
Normal, enfin, si je puis dire.
Quand l'admin Remote Desktop analyse un nouveau client voici la
procédure suivie :
- il ping pour trouver le client
- connexion sur le port 3283 en UDP
- si le précédent ne répond pas il teste le port 5900 en UDP
Est-ce qu'avec ta Livebox tu as bien redirigé ces deux ports en UDP et
TCP et pas en TCP seulement ?
Même si tout semble se faire uniquement en UDP, il faut bien TCP et UDP
pour Remote Desktop.
De plus désinstaller l'admin RD n'est pas nécessaire, tu peux très bien
prendre le contrôle d'un poste qui a ce dernier installé. Par défaut,
quand il est lancé, tu ne peux pas contrôler, mais ça se modifie dans
les préférences Sécurité (un truc, en français, du genre "Autoriser le
contrôle de cet ordinateur quand cette application est lancée").
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
- mais en externe (adresse dyndns), le mac apparaît en "VNC activé" (icône bleu clair) et non en "disponible" et effectivement je peux y accéder en VNC (mais pas avec les fonctionnalités ARD et en particulier pas le glisser-copier entre les bureaux). - OR (et c'est là que ça devient baroque), sur le MINI, la fonctionnalité VNC est *décochée* dans les réglages de partage, et décochée aussi dans les options utilisateurs d'ARD.
Normal, enfin, si je puis dire.
Quand l'admin Remote Desktop analyse un nouveau client voici la procédure suivie :
- il ping pour trouver le client - connexion sur le port 3283 en UDP - si le précédent ne répond pas il teste le port 5900 en UDP
Est-ce qu'avec ta Livebox tu as bien redirigé ces deux ports en UDP et TCP et pas en TCP seulement ?
Même si tout semble se faire uniquement en UDP, il faut bien TCP et UDP pour Remote Desktop.
De plus désinstaller l'admin RD n'est pas nécessaire, tu peux très bien prendre le contrôle d'un poste qui a ce dernier installé. Par défaut, quand il est lancé, tu ne peux pas contrôler, mais ça se modifie dans les préférences Sécurité (un truc, en français, du genre "Autoriser le contrôle de cet ordinateur quand cette application est lancée").
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Gerald
Laurent Pertois wrote:
- il ping pour trouver le client - connexion sur le port 3283 en UDP - si le précédent ne répond pas il teste le port 5900 en UDP
Est-ce qu'avec ta Livebox tu as bien redirigé ces deux ports en UDP et TCP et pas en TCP seulement ?
Bravo ! Effectivement l'ouverture de ces ports en UDP "aussi" permet enfin un accès ARD "vrai". Franchement ce n'est pas documenté avec une grande clarté ! Grand merci.
Par contre le mystère s'épaissit encore : ARD refuse de voir un même ordi *à la fois* en réseau "local" et en réseau "distant" : si je tape l''adresse réseau local, il le voit bien dans le scanneur, je glisse alors l'ordi (qui est bien en bleu foncé, enfin !) dans mon dossier "Maison" mais si je vais voir dans mon dossier distant, il a perdu son nom, est devenu noir, et porte l'adresse IP 0.0.0.0.
Si alors je retourne scanner vers mon adresse dyndns reroutée par la livebox, il voit bien mon ordi (en bleu foncé, aaaah !), avec son adresse IP externe attribuée par Wanaschtroumpf. Tout va bien, je le glisse dans mon dossier "Distants" et si je retourne voir mon dossier "Maison", il est bien en bleu mais ARD lui a réattribué l'adresse externe. Magique mais c'est fromage OU dessert. On ne peut pas garder les deux configs en mémoire simultanément.
- il ping pour trouver le client
- connexion sur le port 3283 en UDP
- si le précédent ne répond pas il teste le port 5900 en UDP
Est-ce qu'avec ta Livebox tu as bien redirigé ces deux ports en UDP et
TCP et pas en TCP seulement ?
Bravo ! Effectivement l'ouverture de ces ports en UDP "aussi" permet
enfin un accès ARD "vrai". Franchement ce n'est pas documenté avec une
grande clarté ! Grand merci.
Par contre le mystère s'épaissit encore : ARD refuse de voir un même
ordi *à la fois* en réseau "local" et en réseau "distant" : si je tape
l''adresse réseau local, il le voit bien dans le scanneur, je glisse
alors l'ordi (qui est bien en bleu foncé, enfin !) dans mon dossier
"Maison" mais si je vais voir dans mon dossier distant, il a perdu son
nom, est devenu noir, et porte l'adresse IP 0.0.0.0.
Si alors je retourne scanner vers mon adresse dyndns reroutée par la
livebox, il voit bien mon ordi (en bleu foncé, aaaah !), avec son
adresse IP externe attribuée par Wanaschtroumpf. Tout va bien, je le
glisse dans mon dossier "Distants" et si je retourne voir mon dossier
"Maison", il est bien en bleu mais ARD lui a réattribué l'adresse
externe. Magique mais c'est fromage OU dessert. On ne peut pas garder
les deux configs en mémoire simultanément.
- il ping pour trouver le client - connexion sur le port 3283 en UDP - si le précédent ne répond pas il teste le port 5900 en UDP
Est-ce qu'avec ta Livebox tu as bien redirigé ces deux ports en UDP et TCP et pas en TCP seulement ?
Bravo ! Effectivement l'ouverture de ces ports en UDP "aussi" permet enfin un accès ARD "vrai". Franchement ce n'est pas documenté avec une grande clarté ! Grand merci.
Par contre le mystère s'épaissit encore : ARD refuse de voir un même ordi *à la fois* en réseau "local" et en réseau "distant" : si je tape l''adresse réseau local, il le voit bien dans le scanneur, je glisse alors l'ordi (qui est bien en bleu foncé, enfin !) dans mon dossier "Maison" mais si je vais voir dans mon dossier distant, il a perdu son nom, est devenu noir, et porte l'adresse IP 0.0.0.0.
Si alors je retourne scanner vers mon adresse dyndns reroutée par la livebox, il voit bien mon ordi (en bleu foncé, aaaah !), avec son adresse IP externe attribuée par Wanaschtroumpf. Tout va bien, je le glisse dans mon dossier "Distants" et si je retourne voir mon dossier "Maison", il est bien en bleu mais ARD lui a réattribué l'adresse externe. Magique mais c'est fromage OU dessert. On ne peut pas garder les deux configs en mémoire simultanément.
Perfectible, tout ça !
-- Gérald
jperrocheau
Laurent Pertois wrote:
Même si tout semble se faire uniquement en UDP, il faut bien TCP et UDP pour Remote Desktop.
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur le bouton "Edit..." une fois la ligne "Apple Remote Desktop" sélectionnée.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
Même si tout semble se faire uniquement en UDP, il faut bien TCP et UDP pour Remote Desktop.
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur le bouton "Edit..." une fois la ligne "Apple Remote Desktop" sélectionnée.
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
laurent.pertois
Jacques Perrocheau wrote:
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur le bouton "Edit..." une fois la ligne "Apple Remote Desktop" sélectionnée.
Euh, expliqué, disons, "mentionné" :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur
le bouton "Edit..." une fois la ligne "Apple Remote Desktop"
sélectionnée.
Euh, expliqué, disons, "mentionné" :)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur le bouton "Edit..." une fois la ligne "Apple Remote Desktop" sélectionnée.
Euh, expliqué, disons, "mentionné" :)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
jperrocheau
Laurent Pertois wrote:
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur le bouton "Edit..." une fois la ligne "Apple Remote Desktop" sélectionnée.
Euh, expliqué, disons, "mentionné" :)
Oui, j'en conviens.
Quand on découvre, cela constitue malgré tout une explication. ;)
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
C'est expliqué dans le TdB "Partage" à l'onglet Firewall en cliquant sur le bouton "Edit..." une fois la ligne "Apple Remote Desktop" sélectionnée.
Euh, expliqué, disons, "mentionné" :)
Oui, j'en conviens.
Quand on découvre, cela constitue malgré tout une explication. ;)
-- Jacques PERROCHEAU ________________________________________________________________________ e-mail: mailto:
laurent.pertois
Jacques Perrocheau wrote:
Quand on découvre, cela constitue malgré tout une explication. ;)
Yep et une bonne piste quand on cherche ce qui ne passe pas.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau <jperrocheau@mac.com.invalid> wrote:
Quand on découvre, cela constitue malgré tout une explication. ;)
Yep et une bonne piste quand on cherche ce qui ne passe pas.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Quand on découvre, cela constitue malgré tout une explication. ;)
Yep et une bonne piste quand on cherche ce qui ne passe pas.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
