j'etais plutot content d'1&1 jusqu'=E0 aujourd'hui mais la franchement
.=2E.
il y a quelques jours , j'essaye leurs taches cron , je rentre tout en
ssh et pour tester je met l'execution toutes les minutes ( pendant
quelques minutes , un petit fichier de test ).
la tache ne fonctionne pas , forcemment , ils ont une configuration
totallement hallucinante et le cron daemon semble etre dans un endroit
inacessible ( en tout cas , pas trouv=E9 ) , je laisse donc tout comme
=E7a , en pensant qu'ils redemarrent le cron pour tout les clients
quotidiennement.
les jours passent , la tache ne fonctionne toujours pas , mais je
recois un mail du support qui me dit que mon compte va etre bloqu=E9 si
je ne r=E9gle pas le probleme dans la seconde.
pour leur faire plaisir , je modifie l'execution et je la met toutes
les heures , j'envoi une r=E9ponse au support en pr=E9cisant que la tache
ne fonctionne pas ( sous entendu si vous avez plus d'infos je suis
preneur ) et que donc =E7a n'avait aucune incidence ...
aujourd'hui je recois le meme mail ( votre compte va etre suspendu bla
bla bla ) , donc ils n'ont meme pas v=E9rifi=E9 que les changements
avaient =E9t=E9 effectu=E9 et pire ils ne connaissent visiblement pas leur
propre infrastructure et ne sont donc pas capable de me dire o=F9 se
trouve le cron daemon , ils ne sont pas non plus capable apparement de
faire la difference entre une tache qui s'execute et une tache qui ne
s'execute pas, bref =E7a fait peur ...
j'etais plutot content d'1&1 jusqu'à aujourd'hui mais la franchement ...
Pas d'bol, tu devais être le dernier !! ;-))
RURA Emma
la tache ne fonctionne pas , forcemment , ils ont une configuration totallement hallucinante
Qu'appelles tu une configuration hallucinante ?
et le cron daemon semble etre dans un endroit inacessible ( en tout cas , pas trouvé )
C'est quoi pour toi un endroit incessible ? De toute façon sur un hébergement mutualisé, c'est normal que tu n'aies pas la possibilité de toucher au Cron Daemon
je laisse donc tout comme ça ,
Est-ce que d'enlever la tâche cron t'aurais coûté tellement de temp s ?
en pensant qu'ils redemarrent le cron pour tout les clients quotidiennement.
Alors là, j'arrive pas à voir comment tu penses 8-). Cela voudrait di re que tout les jours toutes les tâches cron sont effacées. Où est alo rs encore l'intérêt des tâches cron ? L'intérêt est de pouvoir lan cer par exemple un backup de base SQL toutes les jours à 3h00 du matin.
les jours passent , la tache ne fonctionne toujours pas
Qu'est ce qui ne marchait pas ? A mon avis c'était pas le cron qui ne fonctionnait pas, mais le script ou la commande exécutée.
mais je recois un mail du support qui me dit que mon compte va etre bloqué si je ne régle pas le probleme dans la seconde.
En même temps, imagine que même seulement 10% des X clients qui sont sur le même serveur que toi face tous la même chose, tu serais certaineme nt le premier à appeler la Hot-Line en hurlant pour leur dire que le serveur est lent et qu'ils doivent rétablir ça dans la minute qui sui t.
j'envoi une réponse au support en précisant que la tache ne fonctionne pas ( sous entendu si vous avez plus d'infos je suis preneur )
Que le script ou la commande exécutée par la tâche cron ne fonction ne pas, ça veut déjà pas dire grand chose.
et que donc ça n'avait aucune incidence ...
Que cela n'a aucune incidence, je n'y crois vraiment pas. Je pense que d'autres personnes plus expérimentées pourront te confirmer.
et pire ils ne connaissent visiblement pas leur propre infrastructure et ne sont donc pas capable de me dire où se trouve le cron daemon
J'utilise peu les tâches cron , mais je ne vois pas l'utilité d'avoir cette information, et d'ailleurs je ne la connais pas et cela ne m'empêche pas de les utiliser.
ils ne sont pas non plus capable apparement de faire la difference entre une tache qui s'execute et une tache qui ne s'execute pas, bref ça fait peur ...
Encore une fois, je pense que c'est toi qui est pas clair quand tu expliques : le cron marche probablement très bien, mais pas la commande ou script lancé ne fonctionne pas.
-- RURA Emma
la tache ne fonctionne pas , forcemment , ils ont une configuration
totallement hallucinante
Qu'appelles tu une configuration hallucinante ?
et le cron daemon semble etre dans un endroit
inacessible ( en tout cas , pas trouvé )
C'est quoi pour toi un endroit incessible ? De toute façon sur un
hébergement mutualisé, c'est normal que tu n'aies pas la possibilité de
toucher au Cron Daemon
je laisse donc tout comme
ça ,
Est-ce que d'enlever la tâche cron t'aurais coûté tellement de temp s ?
en pensant qu'ils redemarrent le cron pour tout les clients
quotidiennement.
Alors là, j'arrive pas à voir comment tu penses 8-). Cela voudrait di re
que tout les jours toutes les tâches cron sont effacées. Où est alo rs
encore l'intérêt des tâches cron ? L'intérêt est de pouvoir lan cer par
exemple un backup de base SQL toutes les jours à 3h00 du matin.
les jours passent , la tache ne fonctionne toujours pas
Qu'est ce qui ne marchait pas ? A mon avis c'était pas le cron qui ne
fonctionnait pas, mais le script ou la commande exécutée.
mais je
recois un mail du support qui me dit que mon compte va etre bloqué si
je ne régle pas le probleme dans la seconde.
En même temps, imagine que même seulement 10% des X clients qui sont sur
le même serveur que toi face tous la même chose, tu serais certaineme nt
le premier à appeler la Hot-Line en hurlant pour leur dire que le
serveur est lent et qu'ils doivent rétablir ça dans la minute qui sui t.
j'envoi une réponse au support en précisant que la tache
ne fonctionne pas ( sous entendu si vous avez plus d'infos je suis
preneur )
Que le script ou la commande exécutée par la tâche cron ne fonction ne
pas, ça veut déjà pas dire grand chose.
et que donc ça n'avait aucune incidence ...
Que cela n'a aucune incidence, je n'y crois vraiment pas. Je pense que
d'autres personnes plus expérimentées pourront te confirmer.
et pire ils ne connaissent visiblement pas leur
propre infrastructure et ne sont donc pas capable de me dire où se
trouve le cron daemon
J'utilise peu les tâches cron , mais je ne vois pas l'utilité d'avoir
cette information, et d'ailleurs je ne la connais pas et cela ne
m'empêche pas de les utiliser.
ils ne sont pas non plus capable apparement de
faire la difference entre une tache qui s'execute et une tache qui ne
s'execute pas, bref ça fait peur ...
Encore une fois, je pense que c'est toi qui est pas clair quand tu
expliques : le cron marche probablement très bien, mais pas la commande
ou script lancé ne fonctionne pas.
la tache ne fonctionne pas , forcemment , ils ont une configuration totallement hallucinante
Qu'appelles tu une configuration hallucinante ?
et le cron daemon semble etre dans un endroit inacessible ( en tout cas , pas trouvé )
C'est quoi pour toi un endroit incessible ? De toute façon sur un hébergement mutualisé, c'est normal que tu n'aies pas la possibilité de toucher au Cron Daemon
je laisse donc tout comme ça ,
Est-ce que d'enlever la tâche cron t'aurais coûté tellement de temp s ?
en pensant qu'ils redemarrent le cron pour tout les clients quotidiennement.
Alors là, j'arrive pas à voir comment tu penses 8-). Cela voudrait di re que tout les jours toutes les tâches cron sont effacées. Où est alo rs encore l'intérêt des tâches cron ? L'intérêt est de pouvoir lan cer par exemple un backup de base SQL toutes les jours à 3h00 du matin.
les jours passent , la tache ne fonctionne toujours pas
Qu'est ce qui ne marchait pas ? A mon avis c'était pas le cron qui ne fonctionnait pas, mais le script ou la commande exécutée.
mais je recois un mail du support qui me dit que mon compte va etre bloqué si je ne régle pas le probleme dans la seconde.
En même temps, imagine que même seulement 10% des X clients qui sont sur le même serveur que toi face tous la même chose, tu serais certaineme nt le premier à appeler la Hot-Line en hurlant pour leur dire que le serveur est lent et qu'ils doivent rétablir ça dans la minute qui sui t.
j'envoi une réponse au support en précisant que la tache ne fonctionne pas ( sous entendu si vous avez plus d'infos je suis preneur )
Que le script ou la commande exécutée par la tâche cron ne fonction ne pas, ça veut déjà pas dire grand chose.
et que donc ça n'avait aucune incidence ...
Que cela n'a aucune incidence, je n'y crois vraiment pas. Je pense que d'autres personnes plus expérimentées pourront te confirmer.
et pire ils ne connaissent visiblement pas leur propre infrastructure et ne sont donc pas capable de me dire où se trouve le cron daemon
J'utilise peu les tâches cron , mais je ne vois pas l'utilité d'avoir cette information, et d'ailleurs je ne la connais pas et cela ne m'empêche pas de les utiliser.
ils ne sont pas non plus capable apparement de faire la difference entre une tache qui s'execute et une tache qui ne s'execute pas, bref ça fait peur ...
Encore une fois, je pense que c'est toi qui est pas clair quand tu expliques : le cron marche probablement très bien, mais pas la commande ou script lancé ne fonctionne pas.
-- RURA Emma
Harry
Pas d'bol, tu devais être le dernier !! ;-))
Pour l'instant, les quelques individus qui se plaignent de 1&1 ici soit se sont trompé lourdement sur leur problème et n'ont pas lu les FAQ (ce sont souvent les plus virulents), soit sont de mauvaise foi (ce sont souvent ceux qui croient faire de l'ironie, n'est-ce-pas). 1&1 est un excellent hébergeur à tous points de vue. Il reste donc des clients, et beaucoup, comme moi, qui en sont très contents.
Pas d'bol, tu devais être le dernier !! ;-))
Pour l'instant, les quelques individus qui se plaignent de 1&1 ici soit
se sont trompé lourdement sur leur problème et n'ont pas lu les FAQ (ce
sont souvent les plus virulents), soit sont de mauvaise foi (ce sont
souvent ceux qui croient faire de l'ironie, n'est-ce-pas). 1&1 est un
excellent hébergeur à tous points de vue. Il reste donc des clients, et
beaucoup, comme moi, qui en sont très contents.
Pour l'instant, les quelques individus qui se plaignent de 1&1 ici soit se sont trompé lourdement sur leur problème et n'ont pas lu les FAQ (ce sont souvent les plus virulents), soit sont de mauvaise foi (ce sont souvent ceux qui croient faire de l'ironie, n'est-ce-pas). 1&1 est un excellent hébergeur à tous points de vue. Il reste donc des clients, et beaucoup, comme moi, qui en sont très contents.
Xaero
bla bla bla , sans interet
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond aprés une modif des crontab , c'est une habitude à prendre sur des systemes unix , quand on modifie quelque chose , on redemarre le service conçerné, c'est une question de bon sens.
mais j'ai quand meme cherché l'origine de ces problemes chez 1&1 ( ayant abandonné toute espoir d'obtenir une aide venant d'un support tout juste bon à menacer les clients ) , en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
où y est un numero qui n'a aucun sens et qui sert visiblement à classer les differents comptes clients d'1&1 selon une logique qui m'échape , où xxxxx est un nombre qui n'est pas le numero client mais le numero interne d'un dossier qui contient tout les fichiers des clients 1&1 et qu'il faut visiblement deviner à coup de grep sur un des fichiers qu'on heberge... si quelqu'un trouve ça intuitif , il doit forcement bosser chez 1&1.
si 1&1 avaient voulu que les clients n'exploitent pas toutes les possibilité de leur pack et surtout pas les taches cron , je pense qu'ils ne s'y seraient pas pris autrement, je ne dis jamais du mal gratuitement d'un hebergeur mais la franchement , leur systeme est mal foutu et pas du tout documenté , alors forcement 1&1 sera parfait pour le client lambda qui fait une utilisation tres classique de son pack mais sinon bof , c'est un hebergeur qui est clairement mal barré pour concurencer les discounters français ama.
bla bla bla , sans interet
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans
que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés
etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond
aprés une modif des crontab , c'est une habitude à prendre sur des
systemes unix , quand on modifie quelque chose , on redemarre le
service conçerné, c'est une question de bon sens.
mais j'ai quand meme cherché l'origine de ces problemes chez 1&1 (
ayant abandonné toute espoir d'obtenir une aide venant d'un support
tout juste bon à menacer les clients ) , en fait la raison est simple
, voila à quoi ressemble le chemin d'accé vers un fichier mis en
ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
où y est un numero qui n'a aucun sens et qui sert visiblement à
classer les differents comptes clients d'1&1 selon une logique qui
m'échape , où xxxxx est un nombre qui n'est pas le numero client mais
le numero interne d'un dossier qui contient tout les fichiers des
clients 1&1 et qu'il faut visiblement deviner à coup de grep sur un
des fichiers qu'on heberge... si quelqu'un trouve ça intuitif , il
doit forcement bosser chez 1&1.
si 1&1 avaient voulu que les clients n'exploitent pas toutes les
possibilité de leur pack et surtout pas les taches cron , je pense
qu'ils ne s'y seraient pas pris autrement, je ne dis jamais du mal
gratuitement d'un hebergeur mais la franchement , leur systeme est mal
foutu et pas du tout documenté , alors forcement 1&1 sera parfait pour
le client lambda qui fait une utilisation tres classique de son pack
mais sinon bof , c'est un hebergeur qui est clairement mal barré pour
concurencer les discounters français ama.
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond aprés une modif des crontab , c'est une habitude à prendre sur des systemes unix , quand on modifie quelque chose , on redemarre le service conçerné, c'est une question de bon sens.
mais j'ai quand meme cherché l'origine de ces problemes chez 1&1 ( ayant abandonné toute espoir d'obtenir une aide venant d'un support tout juste bon à menacer les clients ) , en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
où y est un numero qui n'a aucun sens et qui sert visiblement à classer les differents comptes clients d'1&1 selon une logique qui m'échape , où xxxxx est un nombre qui n'est pas le numero client mais le numero interne d'un dossier qui contient tout les fichiers des clients 1&1 et qu'il faut visiblement deviner à coup de grep sur un des fichiers qu'on heberge... si quelqu'un trouve ça intuitif , il doit forcement bosser chez 1&1.
si 1&1 avaient voulu que les clients n'exploitent pas toutes les possibilité de leur pack et surtout pas les taches cron , je pense qu'ils ne s'y seraient pas pris autrement, je ne dis jamais du mal gratuitement d'un hebergeur mais la franchement , leur systeme est mal foutu et pas du tout documenté , alors forcement 1&1 sera parfait pour le client lambda qui fait une utilisation tres classique de son pack mais sinon bof , c'est un hebergeur qui est clairement mal barré pour concurencer les discounters français ama.
Mat Free
tout juste bon à menacer les clients ) , en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
où y est un numero qui n'a aucun sens et qui sert visiblement à classer les differents comptes clients d'1&1 selon une logique qui m'échape , où xxxxx est un nombre qui n'est pas le numero client mais le numero interne d'un dossier qui contient tout les fichiers des clients 1&1 et qu'il faut visiblement deviner à coup de grep sur un des fichiers qu'on heberge... si quelqu'un trouve ça intuitif , il doit forcement bosser chez 1&1.
DOCUMENT_ROOT ?
-- Mat
tout juste bon à menacer les clients ) , en fait la raison est simple
, voila à quoi ressemble le chemin d'accé vers un fichier mis en
ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
où y est un numero qui n'a aucun sens et qui sert visiblement à
classer les differents comptes clients d'1&1 selon une logique qui
m'échape , où xxxxx est un nombre qui n'est pas le numero client mais
le numero interne d'un dossier qui contient tout les fichiers des
clients 1&1 et qu'il faut visiblement deviner à coup de grep sur un
des fichiers qu'on heberge... si quelqu'un trouve ça intuitif , il
doit forcement bosser chez 1&1.
tout juste bon à menacer les clients ) , en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
où y est un numero qui n'a aucun sens et qui sert visiblement à classer les differents comptes clients d'1&1 selon une logique qui m'échape , où xxxxx est un nombre qui n'est pas le numero client mais le numero interne d'un dossier qui contient tout les fichiers des clients 1&1 et qu'il faut visiblement deviner à coup de grep sur un des fichiers qu'on heberge... si quelqu'un trouve ça intuitif , il doit forcement bosser chez 1&1.
DOCUMENT_ROOT ?
-- Mat
Spyou
bla bla bla , sans interet
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond aprés une modif des crontab , c'est une habitude à prendre sur des systemes unix , quand on modifie quelque chose , on redemarre le service conçerné, c'est une question de bon sens.
Mauvais unix, changez d'unix.
J'ai jamais relancé crond après avoir modifié une tab.
bla bla bla , sans interet
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans
que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés
etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond
aprés une modif des crontab , c'est une habitude à prendre sur des
systemes unix , quand on modifie quelque chose , on redemarre le
service conçerné, c'est une question de bon sens.
Mauvais unix, changez d'unix.
J'ai jamais relancé crond après avoir modifié une tab.
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond aprés une modif des crontab , c'est une habitude à prendre sur des systemes unix , quand on modifie quelque chose , on redemarre le service conçerné, c'est une question de bon sens.
Mauvais unix, changez d'unix.
J'ai jamais relancé crond après avoir modifié une tab.
Arnaud Launay
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix. J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu comprends, c'est un spécialiste, nous on n'y connaît rien...
ça fait plus de 3 ans [...] que j'ai eu à gerer des serveurs dédi és etc ... , [...]
en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/ [...]
si 1&1 avaient voulu que les clients n'exploitent pas toutes les possibilité de leur pack et surtout pas les taches cron , je pense qu'ils ne s'y seraient pas pris autrement, [etc.]
J'avoue, c'était tres dur :
login as: x01234567 's password: Achtung!
Aus Sicherheitsgründen werden sämtliche SSH- und Telnet-Sitzungen protokolliert und gegebenenfalls überwacht. Wenn Sie sich einloggen, geben Sie diesen Maßnahmen Ihre implizite Zustimmung.
Der Zugriff per SSH/Telnet auf Ihren Webspace wird zum Zweck der Web-Entwicklung zur Verfügung gestellt. Nicht gestattet hingegen ist der Missbrauch zum Betreiben von IRC-Bots, beliebigen Serverdiensten (z.B. Game-Server) oder Cracking-Software. Die Missachtung der oben genannten Bestimmungen kann eine Kündigung Ihres Vertrages nach sich ziehen. -- Warning!
For security reasons all ssh and telnet sessions are logged, and may be monitored. By logging in you give consent to these conditions.
Shell access is provided for web development and not for running irc-bots, arbitrary tcp/udp servers (e.g. gameservers) or cracking toolkits. Disregard may lead to suspension of your contract. --- Attention ! Pour des raisons de sécurité, toutes les sessions SSH sont enregistrées et surveillées. En vous connectant, vous acceptez ces conditions.
L'accès SSH est mis à disposition uniquement dans le but de créer des sites Web. Il est formellement interdit d'utiliser cet accès à d'autres fins, comme l'exploitation de robots IRC et d'applications serveurs (serveurs de jeux, par exemple) ou l'emploi de cracks. Tout manquement à ces dispositions peut entraîner la résiliation de votre contrat. x01234567:~ > pwd /kunden/homepages/99/a123456789/htdocs x01234567:~ >
C'était vraiment d'une extreme complexité. Un crontab se trouve effectivement dans le repertoire /htdocs.
ça fait plus de 3 ans [...] que j'ai eu à gerer des serveurs dédi és
etc ... ,
[...]
en fait la raison est simple
, voila à quoi ressemble le chemin d'accé vers un fichier mis en
ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
[...]
si 1&1 avaient voulu que les clients n'exploitent pas toutes les
possibilité de leur pack et surtout pas les taches cron , je pense
qu'ils ne s'y seraient pas pris autrement, [etc.]
Aus Sicherheitsgründen werden sämtliche SSH- und Telnet-Sitzungen
protokolliert
und gegebenenfalls überwacht. Wenn Sie sich einloggen, geben Sie
diesen
Maßnahmen Ihre implizite Zustimmung.
Der Zugriff per SSH/Telnet auf Ihren Webspace wird zum Zweck der
Web-Entwicklung zur Verfügung gestellt. Nicht gestattet hingegen ist
der
Missbrauch zum Betreiben von IRC-Bots, beliebigen Serverdiensten
(z.B. Game-Server) oder Cracking-Software.
Die Missachtung der oben genannten Bestimmungen kann eine Kündigung
Ihres Vertrages nach sich ziehen.
--
Warning!
For security reasons all ssh and telnet sessions are logged, and may
be monitored. By logging in you give consent to these conditions.
Shell access is provided for web development and not for running
irc-bots, arbitrary tcp/udp servers (e.g. gameservers) or cracking
toolkits.
Disregard may lead to suspension of your contract.
---
Attention !
Pour des raisons de sécurité, toutes les sessions SSH sont
enregistrées et
surveillées. En vous connectant, vous acceptez ces conditions.
L'accès SSH est mis à disposition uniquement dans le but de créer
des sites
Web. Il est formellement interdit d'utiliser cet accès à d'autres
fins, comme
l'exploitation de robots IRC et d'applications serveurs (serveurs de
jeux, par
exemple) ou l'emploi de cracks.
Tout manquement à ces dispositions peut entraîner la résiliation de
votre
contrat.
x01234567:~ > pwd
/kunden/homepages/99/a123456789/htdocs
x01234567:~ >
C'était vraiment d'une extreme complexité.
Un crontab se trouve effectivement dans le repertoire /htdocs.
ça fait plus de 3 ans [...] que j'ai eu à gerer des serveurs dédi és etc ... , [...]
en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/ [...]
si 1&1 avaient voulu que les clients n'exploitent pas toutes les possibilité de leur pack et surtout pas les taches cron , je pense qu'ils ne s'y seraient pas pris autrement, [etc.]
J'avoue, c'était tres dur :
login as: x01234567 's password: Achtung!
Aus Sicherheitsgründen werden sämtliche SSH- und Telnet-Sitzungen protokolliert und gegebenenfalls überwacht. Wenn Sie sich einloggen, geben Sie diesen Maßnahmen Ihre implizite Zustimmung.
Der Zugriff per SSH/Telnet auf Ihren Webspace wird zum Zweck der Web-Entwicklung zur Verfügung gestellt. Nicht gestattet hingegen ist der Missbrauch zum Betreiben von IRC-Bots, beliebigen Serverdiensten (z.B. Game-Server) oder Cracking-Software. Die Missachtung der oben genannten Bestimmungen kann eine Kündigung Ihres Vertrages nach sich ziehen. -- Warning!
For security reasons all ssh and telnet sessions are logged, and may be monitored. By logging in you give consent to these conditions.
Shell access is provided for web development and not for running irc-bots, arbitrary tcp/udp servers (e.g. gameservers) or cracking toolkits. Disregard may lead to suspension of your contract. --- Attention ! Pour des raisons de sécurité, toutes les sessions SSH sont enregistrées et surveillées. En vous connectant, vous acceptez ces conditions.
L'accès SSH est mis à disposition uniquement dans le but de créer des sites Web. Il est formellement interdit d'utiliser cet accès à d'autres fins, comme l'exploitation de robots IRC et d'applications serveurs (serveurs de jeux, par exemple) ou l'emploi de cracks. Tout manquement à ces dispositions peut entraîner la résiliation de votre contrat. x01234567:~ > pwd /kunden/homepages/99/a123456789/htdocs x01234567:~ >
C'était vraiment d'une extreme complexité. Un crontab se trouve effectivement dans le repertoire /htdocs.
Monsieur 99
"Xaero" a couché sur son écran le mercredi 28 juin 2006 03:07:57 :
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond aprés une modif des crontab , c'est une habitude à prendre sur des systemes unix , quand on modifie quelque chose , on redemarre le service conçerné, c'est une question de bon sens.
Mouarf, tu voudrais les droit root sur un mutualisé ?
Et puis, heu, ça marche sans problème en ne redémarrant pas le démon cron ...
mais j'ai quand meme cherché l'origine de ces problemes chez 1&1 ( ayant abandonné toute espoir d'obtenir une aide venant d'un support tout juste bon à menacer les clients ) , en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
Pour quelqu'un qui fait des sites web depuis 3 ans, ben il n'y a pas beaucoup de bons réflexes qui ont été appris. On ne met jamais de chemins en dur, on utilise tout ce qui est possible pour les éviter.
Il y a le choix entre le $HOME, le "~".
Et si vraiment, vraiment on ne sait pas trouver la racine de son hébergement chez 1and1, on va dans la configuration des domaines, on coche son domaine, et on clique sur Infos.
Oh, magie, on a la ligne "Répertoire d'accueil" avec le chemin.
"Xaero" <webmaster@xaero-method.com> a couché sur son écran le mercredi
28 juin 2006 03:07:57 :
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans
que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés
etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond
aprés une modif des crontab , c'est une habitude à prendre sur des
systemes unix , quand on modifie quelque chose , on redemarre le
service conçerné, c'est une question de bon sens.
Mouarf, tu voudrais les droit root sur un mutualisé ?
Et puis, heu, ça marche sans problème en ne redémarrant pas le démon
cron ...
mais j'ai quand meme cherché l'origine de ces problemes chez 1&1 (
ayant abandonné toute espoir d'obtenir une aide venant d'un support
tout juste bon à menacer les clients ) , en fait la raison est simple
, voila à quoi ressemble le chemin d'accé vers un fichier mis en
ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
Pour quelqu'un qui fait des sites web depuis 3 ans, ben il n'y a pas
beaucoup de bons réflexes qui ont été appris. On ne met jamais de
chemins en dur, on utilise tout ce qui est possible pour les éviter.
Il y a le choix entre le $HOME, le "~".
Et si vraiment, vraiment on ne sait pas trouver la racine de son
hébergement chez 1and1, on va dans la configuration des domaines, on
coche son domaine, et on clique sur Infos.
Oh, magie, on a la ligne "Répertoire d'accueil" avec le chemin.
"Xaero" a couché sur son écran le mercredi 28 juin 2006 03:07:57 :
alors vite fait , je ne suis pas un débutant , ça fait plus de 3 ans que j'édite des sites web , que j'ai eu à gerer des serveurs dédiés etc ... , oui j'ai pris l'habitude d'avoir à redemarrer le crond aprés une modif des crontab , c'est une habitude à prendre sur des systemes unix , quand on modifie quelque chose , on redemarre le service conçerné, c'est une question de bon sens.
Mouarf, tu voudrais les droit root sur un mutualisé ?
Et puis, heu, ça marche sans problème en ne redémarrant pas le démon cron ...
mais j'ai quand meme cherché l'origine de ces problemes chez 1&1 ( ayant abandonné toute espoir d'obtenir une aide venant d'un support tout juste bon à menacer les clients ) , en fait la raison est simple , voila à quoi ressemble le chemin d'accé vers un fichier mis en ligne : /kunden/homepages/yy/dxxxxxxxxx/htdocs/
Pour quelqu'un qui fait des sites web depuis 3 ans, ben il n'y a pas beaucoup de bons réflexes qui ont été appris. On ne met jamais de chemins en dur, on utilise tout ce qui est possible pour les éviter.
Il y a le choix entre le $HOME, le "~".
Et si vraiment, vraiment on ne sait pas trouver la racine de son hébergement chez 1and1, on va dans la configuration des domaines, on coche son domaine, et on clique sur Infos.
Oh, magie, on a la ligne "Répertoire d'accueil" avec le chemin.
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix. J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu comprends, c'est un spécialiste, nous on n'y connaît rien...
Ce n'est pas parce que vous ne faites pas une chose , que c'est forcement mal , redemarrer le crond , ça ne coute rien et ça prends quoi ... 2 secondes ? ça permet d'etre sur que le crond tourne , et en plus , les modifs de la crontab sont prises en compte instantanément , quand on est méthodique et rigoureux , perdre deux secondes pour se concentrer uniquement sur un seul point , ça ne me parait pas du tout stupide , mais bon chacun sa façon de faire hein , quand on veux etre quelqu'un de fiable on met toutes les chances de son coté pour l'etre ...
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix.
J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu
comprends, c'est un spécialiste, nous on n'y connaît rien...
Ce n'est pas parce que vous ne faites pas une chose , que c'est
forcement mal , redemarrer le crond , ça ne coute rien et ça prends
quoi ... 2 secondes ?
ça permet d'etre sur que le crond tourne , et en plus , les modifs de
la crontab sont prises en compte instantanément , quand on est
méthodique et rigoureux , perdre deux secondes pour se concentrer
uniquement sur un seul point , ça ne me parait pas du tout stupide ,
mais bon chacun sa façon de faire hein , quand on veux etre quelqu'un
de fiable on met toutes les chances de son coté pour l'etre ...
Le Wed, 28 Jun 2006 08:15:28 +0200, Spyou écrivit:
Mauvais unix, changez d'unix. J'ai jamais relancé crond après avoir modifié une tab.
Pas mieux. Mais ça fait trois ans qu'il fait du oueb, alors tu comprends, c'est un spécialiste, nous on n'y connaît rien...
Ce n'est pas parce que vous ne faites pas une chose , que c'est forcement mal , redemarrer le crond , ça ne coute rien et ça prends quoi ... 2 secondes ? ça permet d'etre sur que le crond tourne , et en plus , les modifs de la crontab sont prises en compte instantanément , quand on est méthodique et rigoureux , perdre deux secondes pour se concentrer uniquement sur un seul point , ça ne me parait pas du tout stupide , mais bon chacun sa façon de faire hein , quand on veux etre quelqu'un de fiable on met toutes les chances de son coté pour l'etre ...
