annonce intéressante mais la rémunération semble un peu juste si on tient compte de l'extrème polyvalence requise.
c'est un peu le mouton à 5 pattes j'ai l'impression et puis manipuler autant de sujets, on risque d'être spécialiste de rien ^^
enfin, c'est pas comme si c'était différent dans les autres boites.
pour ma part, je suis un peu rouillé en debian car ça fait bien trois ans que j'ai rien administré ou presque (à part chez moi), je bosse sur aix à la place. quant aux langages, je connais pas (encore) python etc... donc pour moi c'est juste, et puis bon je suis pas en recherche active.
comme tu as pu t'en rendre compte, il ne s'agit pas d'un vrai serveur apache.
le vrai nom du processus est masqué ce qui fait que tu ne peux pas le voir avec la commande "ps", ça ne veut pas forcément dire que la commande "ps" est compromise, en effet il y a des astuces pour tronquer le nom du process tel qu'il apparait avec "ps", je ne saurais pas te décrire l'astuce mais j'ai déjà rencontré le cas
pour voir le vrai nom du process, tu peux utiliser la commande "lsof | grep LISTEN".
Jette également un coup d'oeil à la cron de "www-data"...
Et oui, tout ceci n'est pas innocent, je me suis déjà fait avoir, un "utilisateur technicien" m'avait installé une saloperie en php et a ouvert une faille (avec remote inclusion etc...), et un petit malin avait installé un robot, mais ce robot n'écoutait pas le port 80...
Etant donné qu'il s'agissait d'un serveur "dans la nature" que je n'administrais plus, je n'avait pas pu prévenir l'utilisateur des failles qu'il pouvait ouvrir...mais quand une banque s'est plainte de phishing, on m'a vite contacté pour comprendre ce qu'il se passait :)
ce robot masquait son nom avec "ps" exactement comme toi. mais comme le "pirate" n'était pas passé root, il n'a pu installer son truc que dans /tmp...
Ce qui est inquiétant dans ton cas, c'est que pour écouter le port 80 il faut être root....donc un coup de chkrootkit me semble quand même important.
je rebondis juste sur ta commande "route", tu veux spécifier une route statique vers un host, or tu spécifies une option "-net".
L'usage normal serait de spécifier l'option "host" à la place de "net", ne pas mettre le masque et de spécifier l'interface comme tu l'as fait.
Etant donné que 91.xx.xx.22 doit être dans le même reseau que 91.xx.xx.11 (si j'ai bien compris) , alors le masque doit-être identique, donc différent de 255.255.255.255 à priori
pourquoi pas, mais après tout la gestion de la cohérence de la mémoire centrale partagée restera d'actualité.
Paralléliser au maximum est une bonne chose mais induit des risques d'incohérence puisque une page peut être accédée par plusieurs cpu en même temps, donc plus on ajoute de cpu/coeur, plus il faut gérer les accès concurrents, et plus on peut perdre en performances.
D'après ce que j'ai pu lire sur le sujet, il existe bon nombre d'algorithme et bon nombre de chercheurs ce sont déjà penché sur le sujet, donc finalement j'ai un peu de mal à voir en quoi augmenter le nb de coeur pose un pb :
est-ce que les algo de gestion de concurrence sont devenus inefficaces ?
Pour illustrer mes propos, le document ci-après illustre quelques algorithme de gestion de concurrence :
ou alors, si on a la main sur le code du process A, on peut traper les signaux et supprimer le verrou automatiquement.
Exemple pour un script :
trap 'rm verrou' 2
On supprime le verrou si on reçoit le signal 2 (SIGINT), à noter qu'on peut le faire sur d'autres signaux, sauf bien sûr SIGKILL, mais bon on utilise rarement le SIGKILL quand même :)
tu sais qu'il existe aussi des informaticiens compétents qui maitrisent des OS comme MVS, Bull GCOS, VMS, Windows, OS400 ?
Tu es au courant que les mainframe existent encore et qu'il y a une population d'informaticien très pointu sur ce créneau ?
De même, il existe de très bons admin windows qui maitrisent à fond leur environnement, ils savent utiliser un langage de script, ils connaissent les fondements de leur système, ils savent même lire la doc (abondante) de microsoft !
je sais, j'ai marché dedans, mais ton troll soit disant de compèt n'en est pas vraiment un, je dirais plutôt que c'est un troll de compétition de niveau hameautal !
ulimit est une commande shell qui ne s'applique qu'au shell en cours et à ses descendants.
Tout à fait, sauf que mes paramètres sont persistants c'est à dire qu'ils sont bien stockés dans le fichier /etc/security/limits d'AIX et donc ils doivent s'appliquer à tous les environnements shell.
La fonction system en perl lance une commande shell. Et donc dans un sous shell puisque perl n'interprète pas le shell :)
Ce n'est pas parce que la commande "ulimit" n'est pas gérée par Perl qu'il y a création d'un nouveau process, c'est juste que c'est la fonction première de system() que de faire un fork() et donc un process shell (sh -c en locurence), donc le shell exécuté est effectivement bien fils de perl..
En effet, on pourrait pu tout aussi bien écrire exec("ulimit -a") où là le shell remplace le process perl le temps de l'exécution, enfin bref, le coeur du problème n'est pas là :-)
Par conséquent ta commande ulimit ne peut être prise en compte par perl qui et le père du shell ayant lancé la commande.
Mais je ne cherche pas à appliquer cette commande à perl, je cherche à comprendre pourquoi l'environnement du shell lancé par Perl est différent des autres !
Pour que la commande s'applique au processus en cours, il faut faire appel directement à l'appel système concerné. Je ne doute pas que tu puisse trouver ton bonheur dans le cpan.
merci mais ce n'est pas ce que je veux faire, je ne cherche pas à appliquer le paramètre au process en cours, et je connais quel est le module en question, il est même proposé dans la première URL de mes recherches.
L'autre solution est de lancer ton script perl dans un script shell qui fera lui-même la commande ulimit avant de lancer perl (son fils cette fois).
Comme précisé plus haut, mes paramètres ulimit sont persistants c'est à dire qu'il n'y a pas besoin de les spécifier au runtime, donc que je lance perl depuis un shell interactif ou non revient au même...
La preuve par l'exemple :
#!/usr/bin/ksh
ulimit -d unlimited
echo "Affichage des params effectifs sous shell"
ulimit -a
echo "Affichage des params effectifs sous le shell lancé par Perl"
perl << EOF
system("ulimit -a");
EOF
et le résultat :
Affichage des params effectifs sous shell
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) unlimited
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) 2000
Affichage des params effectifs sous le shell lancé par Perl
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 2097152
stack(kbytes) unlimited
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) 2000
Tu constates comme moi que le paramètre data n'est pas le même, c'est que ce je ne comprends pas :-/
Mais les comptes utilisateurs sous aix n'existent pas dans la base ODM !
De base c'est comme Linux, des fichiers plats, c'est tout.
Créer un user sous AIX revient à ajouter une ligne dans /etc/passwd, et quand un password est affecté, une entrée est ajouté dans les fichiers /etc/security/user et passwd, c'est tout con puisque ce sont des bases de données à plat.
Tu préfères que les params des devices soient tous dans des fichiers textes ?
Personnlement, je n'ai pas encore rencontré de soucis avec la base ODM, par contre ce qui est déroutant par exemple c'est quand on configure un route réseau, il faut bien penser à changer les valeurs de l'objet inet0, sinon au reboot y a pu :(
Je ne vois pas de quoi tu te plains, tu as une problématique et on te donne la réponse, donc ton problème est résolu.
Maintenant au niveau technique, je suis d'accord que le fait de devoir passer par un logical volume pour mounter une image iso peut paraitre ridicule surtout quand on compare ça à linux, c'est clair.
Après de là à juger l'avenir d'un OS sur une fonctionnalité aussi peu utilisée, franchement faut pas déconner :-)
J'imagine que tu n'es pas admin et developpeur et qu'aix te sort par les cheveux, je suis de tout cœur avec toi, aix dans certains cas est une horreur par rapport à Linux.
Merci de nous avoir fait une petite synthèse des dernières nouveautés du monde apple.
Le problème majeur d'apple, c'est toujours de pratiquer des tarifs élevés, avec le mac book air Apple ne manque vraiment d'air (hu hu).
Si l'idée de rendre le lecteur optique externe n'est pas nouvelle (voir les SONY Vaio de 2001), ne pas le fournir en standard avec la machine lors de l'achat en est une autre ! Il faut ajouter 99$ à l'ardoise déjà salée pour bénéficier du lecteur...c'est proprement scandaleux...comment fait-on pour réinstaller le système (comme tu l'as très justement précisé) ?
On boot sur une clé USB, via le réseau ?
Avec les performances annoncée du wifi 802.11n, j'imagine que Apple va nous ressortir tôt ou tard le netBoot d'il y a dix ans avec la possibilité de booter sur une borne AirPort/timecapsule/mescouilles.
Reste ensuite la question du stockage, le disque dur PATA est (je crois), le même que celui de l'ipod, il est donc très lent et relativement fragile, cela nous donne surtout envie de prendre la version avec disque SSD. Mais qu'est-ce qui justifie une telle différence de prix ? Un disque SSD de 64Go vaut-il si cher que ça ? Non, c'est que du buzz et rien que du buzz, Apple continue de se foutre de la gueule du monde, les apple center continuent de crever la dalle en faisant des marges de moins de 5% sur le matos...
Même si apple fait de bons produits d'une manière générale, ils continuent de prendre les consommateurs pour des con (bon, ok c'est pas les seuls hein).
Je pense que ne rechèterai jamais de mac, c'est trop cher pour ce que c'est...je peux très bien me passer de mac os x, windows ou gnu/linux font largement l'affaire....
# intéressant
Posté par Dabowl_92 . En réponse au message Cherche admin Debian confirmé + réseaux. Évalué à 2.
c'est un peu le mouton à 5 pattes j'ai l'impression et puis manipuler autant de sujets, on risque d'être spécialiste de rien ^^
enfin, c'est pas comme si c'était différent dans les autres boites.
pour ma part, je suis un peu rouillé en debian car ça fait bien trois ans que j'ai rien administré ou presque (à part chez moi), je bosse sur aix à la place. quant aux langages, je connais pas (encore) python etc... donc pour moi c'est juste, et puis bon je suis pas en recherche active.
# you've been hacked
Posté par Dabowl_92 . En réponse au message Comportement suspect. Évalué à 4.
le vrai nom du processus est masqué ce qui fait que tu ne peux pas le voir avec la commande "ps", ça ne veut pas forcément dire que la commande "ps" est compromise, en effet il y a des astuces pour tronquer le nom du process tel qu'il apparait avec "ps", je ne saurais pas te décrire l'astuce mais j'ai déjà rencontré le cas
pour voir le vrai nom du process, tu peux utiliser la commande "lsof | grep LISTEN".
Jette également un coup d'oeil à la cron de "www-data"...
Et oui, tout ceci n'est pas innocent, je me suis déjà fait avoir, un "utilisateur technicien" m'avait installé une saloperie en php et a ouvert une faille (avec remote inclusion etc...), et un petit malin avait installé un robot, mais ce robot n'écoutait pas le port 80...
Etant donné qu'il s'agissait d'un serveur "dans la nature" que je n'administrais plus, je n'avait pas pu prévenir l'utilisateur des failles qu'il pouvait ouvrir...mais quand une banque s'est plainte de phishing, on m'a vite contacté pour comprendre ce qu'il se passait :)
ce robot masquait son nom avec "ps" exactement comme toi. mais comme le "pirate" n'était pas passé root, il n'a pu installer son truc que dans /tmp...
Ce qui est inquiétant dans ton cas, c'est que pour écouter le port 80 il faut être root....donc un coup de chkrootkit me semble quand même important.
essaye de nous en dire plus sur ton cas
# merci
Posté par Dabowl_92 . En réponse au journal Qui va gagner la course au Higgs ?. Évalué à 4.
bienvenue sur techno science fr
# variable shell
Posté par Dabowl_92 . En réponse au message timeout ssh. Évalué à 5.
L'idéal c'est de la déclarer en lecture seule dans /etc/profile, comme ça aucun utilisateur ne peut la changer :-) mais c'est un peu brutal.
à mettre dans /etc/profile :
typeset -r TMOUT=<Nombre de secondes>
[^] # Re: Mais... ça existe déjà ?!
Posté par Dabowl_92 . En réponse à la dépêche Bélier 0.6 : Outil d'automatisation de connexions ssh complexes. Évalué à 10.
[^] # Re: -host ?
Posté par Dabowl_92 . En réponse au message OpenVz : Plusieurs IP Failovers pour une même machine virtuelle. Évalué à 1.
# -host ?
Posté par Dabowl_92 . En réponse au message OpenVz : Plusieurs IP Failovers pour une même machine virtuelle. Évalué à 1.
L'usage normal serait de spécifier l'option "host" à la place de "net", ne pas mettre le masque et de spécifier l'interface comme tu l'as fait.
Etant donné que 91.xx.xx.22 doit être dans le même reseau que 91.xx.xx.11 (si j'ai bien compris) , alors le masque doit-être identique, donc différent de 255.255.255.255 à priori
[^] # Re: Le multicoeur va vraiment devenir problématique
Posté par Dabowl_92 . En réponse au journal Le multicoeur va vraiment devenir problématique. Évalué à 1.
Paralléliser au maximum est une bonne chose mais induit des risques d'incohérence puisque une page peut être accédée par plusieurs cpu en même temps, donc plus on ajoute de cpu/coeur, plus il faut gérer les accès concurrents, et plus on peut perdre en performances.
D'après ce que j'ai pu lire sur le sujet, il existe bon nombre d'algorithme et bon nombre de chercheurs ce sont déjà penché sur le sujet, donc finalement j'ai un peu de mal à voir en quoi augmenter le nb de coeur pose un pb :
est-ce que les algo de gestion de concurrence sont devenus inefficaces ?
Pour illustrer mes propos, le document ci-après illustre quelques algorithme de gestion de concurrence :
http://arcad.essi.fr/cours/systeme2/96-cnam-coherence.pdf
Le document date un peu mais finalement l'informatique est un phénomène cyclique ou l'on revient souvent en arrière sur d'anciennes théories :)
[^] # Re: Signification des logs
Posté par Dabowl_92 . En réponse au message log http. Évalué à 3.
Tu veux peut-être parler du système de cache de t33mpl3t ?
[^] # Re: fichier lock ?
Posté par Dabowl_92 . En réponse au message attendre la fin d'un processus créé depuis un autre shell. Évalué à 1.
[^] # Re: fichier lock ?
Posté par Dabowl_92 . En réponse au message attendre la fin d'un processus créé depuis un autre shell. Évalué à 1.
Exemple pour un script :
trap 'rm verrou' 2
On supprime le verrou si on reçoit le signal 2 (SIGINT), à noter qu'on peut le faire sur d'autres signaux, sauf bien sûr SIGKILL, mais bon on utilise rarement le SIGKILL quand même :)
# module bien installé ?
Posté par Dabowl_92 . En réponse au message php fonction ssh2 et libssh2. Évalué à 1.
Peux-tu copier-coller le php.ini et le phpinfo() ?
[^] # Re: en résumé
Posté par Dabowl_92 . En réponse au message quel est le role du fichier etc/resolv.conf. Évalué à 1.
oui c'est ça.
ne pas oublier dans la conf de bind (du service dns) de mettre un forwarder (dns parent ou dns du provider).
# .
Posté par Dabowl_92 . En réponse au sondage La nouvelle page d'accueil Linuxfr. Évalué à -3.
---> ['''] (pas de chance il pleut)
# troll de niveau hameautal
Posté par Dabowl_92 . En réponse au journal Troll de compétition. Évalué à -5.
Tu es au courant que les mainframe existent encore et qu'il y a une population d'informaticien très pointu sur ce créneau ?
De même, il existe de très bons admin windows qui maitrisent à fond leur environnement, ils savent utiliser un langage de script, ils connaissent les fondements de leur système, ils savent même lire la doc (abondante) de microsoft !
je sais, j'ai marché dedans, mais ton troll soit disant de compèt n'en est pas vraiment un, je dirais plutôt que c'est un troll de compétition de niveau hameautal !
# Résolu
Posté par Dabowl_92 . En réponse au message Perl, AIX et les limits. Évalué à 3.
perl -V | grep maxdata
ld='ld', ldflags ='-brtl -bmaxdata:0x80000000 -q64 -b64'
Même les binaires 64 bits sont compilés avec cette option.
Il semblerait bien que ce paramètre influe sur les limit de l'environnement shell généré par Perl via les fonctions system, exec....
Il ne reste plus qu'à recompiler Perl...
[^] # Re: Une histoire de famille
Posté par Dabowl_92 . En réponse au message Perl, AIX et les limits. Évalué à 2.
Tout à fait, sauf que mes paramètres sont persistants c'est à dire qu'ils sont bien stockés dans le fichier /etc/security/limits d'AIX et donc ils doivent s'appliquer à tous les environnements shell.
La fonction system en perl lance une commande shell. Et donc dans un sous shell puisque perl n'interprète pas le shell :)
Ce n'est pas parce que la commande "ulimit" n'est pas gérée par Perl qu'il y a création d'un nouveau process, c'est juste que c'est la fonction première de system() que de faire un fork() et donc un process shell (sh -c en locurence), donc le shell exécuté est effectivement bien fils de perl..
En effet, on pourrait pu tout aussi bien écrire exec("ulimit -a") où là le shell remplace le process perl le temps de l'exécution, enfin bref, le coeur du problème n'est pas là :-)
Par conséquent ta commande ulimit ne peut être prise en compte par perl qui et le père du shell ayant lancé la commande.
Mais je ne cherche pas à appliquer cette commande à perl, je cherche à comprendre pourquoi l'environnement du shell lancé par Perl est différent des autres !
Pour que la commande s'applique au processus en cours, il faut faire appel directement à l'appel système concerné. Je ne doute pas que tu puisse trouver ton bonheur dans le cpan.
merci mais ce n'est pas ce que je veux faire, je ne cherche pas à appliquer le paramètre au process en cours, et je connais quel est le module en question, il est même proposé dans la première URL de mes recherches.
L'autre solution est de lancer ton script perl dans un script shell qui fera lui-même la commande ulimit avant de lancer perl (son fils cette fois).
Comme précisé plus haut, mes paramètres ulimit sont persistants c'est à dire qu'il n'y a pas besoin de les spécifier au runtime, donc que je lance perl depuis un shell interactif ou non revient au même...
La preuve par l'exemple :
#!/usr/bin/ksh
ulimit -d unlimited
echo "Affichage des params effectifs sous shell"
ulimit -a
echo "Affichage des params effectifs sous le shell lancé par Perl"
perl << EOF
system("ulimit -a");
EOF
et le résultat :
Affichage des params effectifs sous shell
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) unlimited
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) 2000
Affichage des params effectifs sous le shell lancé par Perl
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 2097152
stack(kbytes) unlimited
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) 2000
Tu constates comme moi que le paramètre data n'est pas le même, c'est que ce je ne comprends pas :-/
[^] # Re: AIX - Mais quel avenir ?
Posté par Dabowl_92 . En réponse au journal AIX - Mais quel avenir ?. Évalué à 1.
[^] # Re: faut pas chipoter
Posté par Dabowl_92 . En réponse au journal AIX - Mais quel avenir ?. Évalué à 0.
De base c'est comme Linux, des fichiers plats, c'est tout.
Créer un user sous AIX revient à ajouter une ligne dans /etc/passwd, et quand un password est affecté, une entrée est ajouté dans les fichiers /etc/security/user et passwd, c'est tout con puisque ce sont des bases de données à plat.
[^] # Re: l'avenir d'AIX s'appelle....
Posté par Dabowl_92 . En réponse au journal AIX - Mais quel avenir ?. Évalué à 1.
Bon, toujours est-il que la situation n'a pas changé et IBM a encore bon nombre d'utilisateur sur cet OS.
D'autant plus qu'AIX a beaucoup évolué entre temps, et qu'il a bien fallu combler les demandes...
J'ai posté plus haut, la road map d'aix jusqu'en 2015...
[^] # Re: faut pas chipoter
Posté par Dabowl_92 . En réponse au journal AIX - Mais quel avenir ?. Évalué à 1.
Tu préfères que les params des devices soient tous dans des fichiers textes ?
Personnlement, je n'ai pas encore rencontré de soucis avec la base ODM, par contre ce qui est déroutant par exemple c'est quand on configure un route réseau, il faut bien penser à changer les valeurs de l'objet inet0, sinon au reboot y a pu :(
# faut pas chipoter
Posté par Dabowl_92 . En réponse au journal AIX - Mais quel avenir ?. Évalué à 4.
Je ne vois pas de quoi tu te plains, tu as une problématique et on te donne la réponse, donc ton problème est résolu.
Maintenant au niveau technique, je suis d'accord que le fait de devoir passer par un logical volume pour mounter une image iso peut paraitre ridicule surtout quand on compare ça à linux, c'est clair.
Après de là à juger l'avenir d'un OS sur une fonctionnalité aussi peu utilisée, franchement faut pas déconner :-)
J'imagine que tu n'es pas admin et developpeur et qu'aix te sort par les cheveux, je suis de tout cœur avec toi, aix dans certains cas est une horreur par rapport à Linux.
Si ça t'intéresse voici l'avenir d'aix :
http://www.itjungle.com/tug/tug051707-story02.html
# Cerveau trop formaté ?
Posté par Dabowl_92 . En réponse au journal Instruction en ligne de commande mal fiche dans windows. Évalué à -5.
Je ne vois pas en quoi c'est spécialement mal foutu, c'est juste que ça bouleverse tes habitudes parce que la syntaxe est différente.
C'est pas si mal de casser ses habitudes de temps en temps...
# Google
Posté par Dabowl_92 . En réponse au message comment ecrir un script shell en linux. Évalué à 6.
En faisant un copier-coller de ta question dans google, tu obtiens des résultats très satisfaisants :
http://www.google.fr/search?q=comment+puis-je+%C3%A9crire+un(...)
Bon apprentissage
# Le rat porc avec DLFP ?
Posté par Dabowl_92 . En réponse au journal Une nouvelle révolution dans l'informatique et électronique grand public !. Évalué à 10.
Le problème majeur d'apple, c'est toujours de pratiquer des tarifs élevés, avec le mac book air Apple ne manque vraiment d'air (hu hu).
Si l'idée de rendre le lecteur optique externe n'est pas nouvelle (voir les SONY Vaio de 2001), ne pas le fournir en standard avec la machine lors de l'achat en est une autre ! Il faut ajouter 99$ à l'ardoise déjà salée pour bénéficier du lecteur...c'est proprement scandaleux...comment fait-on pour réinstaller le système (comme tu l'as très justement précisé) ?
On boot sur une clé USB, via le réseau ?
Avec les performances annoncée du wifi 802.11n, j'imagine que Apple va nous ressortir tôt ou tard le netBoot d'il y a dix ans avec la possibilité de booter sur une borne AirPort/timecapsule/mescouilles.
Reste ensuite la question du stockage, le disque dur PATA est (je crois), le même que celui de l'ipod, il est donc très lent et relativement fragile, cela nous donne surtout envie de prendre la version avec disque SSD. Mais qu'est-ce qui justifie une telle différence de prix ? Un disque SSD de 64Go vaut-il si cher que ça ? Non, c'est que du buzz et rien que du buzz, Apple continue de se foutre de la gueule du monde, les apple center continuent de crever la dalle en faisant des marges de moins de 5% sur le matos...
Même si apple fait de bons produits d'une manière générale, ils continuent de prendre les consommateurs pour des con (bon, ok c'est pas les seuls hein).
Je pense que ne rechèterai jamais de mac, c'est trop cher pour ce que c'est...je peux très bien me passer de mac os x, windows ou gnu/linux font largement l'affaire....
Je boycott aussi l'iphone car j'ai un viewty...
Apple sucks !