J'ai pas le reste de la trace vu que le bug ne se reproduit plus et que mon term sur cette machine est fermé. Je l'ai retrouvé dans l'historique de mes recherches google.
Perso, je sais pas c'que \312\4 signifie. Si une âme charitable meilleur que moi en c système linux pouvait expliquer …
Pour info, finalement, j'ai juste ré-écrit le script de manière plus lisible.
Et, après avoir re-testé ce matin sur les 2 machines, j'ai à le même comportement :/ pt'être un truc lié au 27 Novembre ? :)
Quoiqu'il en soit, ce bout de truc ne marchait juste pas en ksh alors qu'il marche en bash. Il n'écrit rien, ni sur stdout, ni dans le fichier. Alors que le client utilise ce script depuis des années sans jamais s'en être rendu compte. C'est d'ailleurs pour ça que je l'ai ré-écris.
Ceci dis, par curiosité, si quelqu'un pouvait m’expliquer le pourquoi ça fonctionne en bash et pas en ksh … et éventuellement, qu'est-ce que ça fait exactement.
Pour moi, ça redirige la sortie standard dans un sous shell qui redirige sa sortie standard sur tee.
Le type utilisait ça pour mettre stdout et stderr dans un tee => echo plop 1> >(tee -a $LOG_OUT) 2> >(tee -a $LOG_ERR >&2).
En gros, quand un utilisateur veut accéder à un Directory, Location ou File ou autre, tu lui dis qu'il doit présenter son certificat client.
On parle alors d'authentification SSL dans les 2 sens. (le premier sens est l'authentification du serveur auprès du client)
Il faut évidemment que le client "trust" le certificat du serveur et que le serveur "trust" le certificat du client.
Il me semble que les impots avait essayé de mettre ça en place pendant un temps, ou certaines banques (au moins hsbc).
C'est certainement la manière la plus propre pour faire ce que tu souhaites.
Bon, finalement, les chiffres précédent sont faux parce qu’ils comptes les desk windows ...
En ne prenant que les serveurs, on arrive a :
12 000 unix.
13 000 windows.
Ici dans une banque du coté des activités de marché, on à la louche 50 000 serveurs en tout dont 75% de windows et 25% d'unix.
Dans les 25% d'unix, plus de 70% des serveurs sont sous linux, le reste, c'est du solaris. (peut-être quelques vieux AIX, mais c'est pas significatif).
Comme distrib, c'est exclusivement du redhat.
En chiffre, ça fais à peu près :
35 000 windows
12 000 unix
dont
8000 linux
3500 solaris
Attention, il faut savoir que les linux sont bien souvent mutualisé. Donc plusieurs "services" (comprendre ça un peu comme un container) peuvent être installé sur le même OS.
Donc les chiffres ne représente que les OS installés, pas forcément leur volume d'utilisation. D'autant qu'une partie des windows ne sont utilisé qu'en cas de plan de secours (ils idle 99% de leur temps) alors que les unix ont une méthode plus propre de bascule en plan de secours.
J'utilise homebank depuis bientot 3 ans et il fait presque tout ce que tu demandes.
Faut juste prendre un peu de temps pour le paramètrer, mais pas besoin d'être comptable pour y arriver.
En gros, il existe 3 types de virtualhosts :
- basé sur l'ip
- basé sur le port
- basé sur le host header.
Pour l'ip, il te faut plusieurs @ip public sur ta machine, ce qui j'imagine n'est pas de le cas.
Pour le port, à priori, c'est pas ce que tu veux.
Ce qu'il t faut c'est sur le hostheader de ta requête http.
Donc tu déclares ton namevirtualhost tonip:80, tu déclares ton <VirtualHost tonip:80> et apache se débrouillera avec ce qu'il trouvera dans ServerName pour savoir que c'est bien ce site là qu'il doit fournir.
Si, par exemple, derrière il y a un tomcat ou autre serveur applicatif, tu peux éventuellement t'essayer aux proxypass sur un vhost binder sur la socket tonip:80 qui reécrira tout ce qui va et tout ce qui vient vers ton tomcat. Tu auras donc un apache en frontal et un tomcat derrière. Si c'est le cas, bind ton tomcat sur 127.0.0.1 et utilise le proxypass sur 127.0.0.1. Ton tomcat ne sera alors accessible que via ton apache.
Si c'est pas ce que tu veux, précise ta demande stp.
J'ai eu un peu le même sentiment : "c'est une blague".
On dirait un article de quelqu'un qui découvre l'utilisation du fichier hosts, qui trouve ça formidable et qui se dit qui devrait partager sa découverte avec tout le monde en partageant son énorme fichier hosts.
Ce n'est ni bon pour le particulier, ni pour un entreprise (si petite soit elle) pour toute les raisons déjà relevée.
Comment une dépêche comme ça a pu passer, sérieusement ?
Hormis pour la du dev, je vois pas l'intérêt de binder ton apache sur *:80. Et si tu fais du dev, ben tu déclare proprement ton vhost en 127.0.0.1:80 avec les logs qui vont acces/error qui faut, comme ça tu pourrit pas le reste de tes sites. Sinon, tu le bind sur l'ip qui répondra aux client qui se présente. Un petit effort de conf n'a jamais fais de mal à personne.
Pour moi 127.0.0.1 est fait pour ça. Aucun intérêt de mettre autre chose, si ce n'est se compliquer la vie inutilement.
Si t'as accès a la conf d'apache, mod_proxy permet de faire ce genre de truc.
En gros, avec mod_proxy et de l'url rewriting, tu fais a peu près tout ce que tu peux imaginer et même ce que t'imagines pas ;)
Sinon dans man sshd_config, on découvre un paramètre très utile pour ce genre d'erreur : AllowUsers ... pis tant que tu y es, tu peux aussi rajouter PermitRootLogin no.
C'est aussi valable sous *BSD ;)
Sans être un maniaque de la sécurité, il y a quelques règles très simple à mettre en place sur tout linux fraîchement installé :
- limité le nombre de services réseaux (ou pas) au maximum.
- sécurisé un minimum ces points d'entrées.
Après, utiliser/configurer iptables aux petits oignons sur un desktop, c'est plus un luxe que vraiment utile amha.
En fait, je m'en doutais par le comportement du truc qui laissait vraiment penser ça, mais je voulais confirmation de mes doutes.
Pour le problème dans son ensemble (ou presque), je suis dans un while getopts blablabla, ou toutes mes options font appel a des fonctions et certaines étaient récurentes.
Vu que j'aime pas les trucs récurents dans mes scripts, je les ai sortis du while et là, c le drame :)
Sinon, le pipe était pour rediriger l'ensemble de mon while dans un tee pour pouvoir laisser la log et afficher la sortie. J'ai trouver ça assez classe de gerer l'ensemble de mes sorties (stdout, stderr + log) avec un | tee $LOG bien placer, mais vu que ça fou le bordel ...
Maintenant que j'ai confirmation, va falloir ou choisir comment loger mieux (peut-être avec un fifo (merci wismerhill )) ou remettre mes fonctions redondante dans mes options de getopts.
En bref, je devrais m'en sortir, mais merci pour ta propositions :)
Désolé de pas mettre la solution direct sur le site, mais j'ai passé plus de temps à essayé d'avoir un affichage correct plutot qu'a débugger ton truc :s
Je pense qu'il est très au courant des 4 points que tu mentionnes, surtout le 3, vu que ce monsieur est l'un des papa de linuxfr.
Je pense que s'il à fait cette applications, c'est qu'elle répond au moins à un de ses besoins, et s'il vient en parler, c'est pour voir si ça intéresse d'autres gens et si ces mêmes gens n'auraient pas des suggestions pour améliorer cette petite appli.
# man bash
Posté par Cereal Killer . En réponse au message ajouter une entrée fstab en bash. Évalué à 3.
juste un petit read -s pour le mot de passe.
pas indispensable, mais ça fait plus sérieux.
[^] # Re: strace un jour, strace toujours
Posté par Cereal Killer . En réponse au message Comportement bizarre de redirection en ksh. Évalué à 1.
Le permission denied venait bien de ce bout de code et spécifiquement de cette empilement de redirection.
J'ai aussi pensé au strace, et voilà c'que ça disais :
open("\312\4", O_WRONLY|O_CREAT|O_TRUNC, 0666) = -1 EACCES (Permission denied)
J'ai pas le reste de la trace vu que le bug ne se reproduit plus et que mon term sur cette machine est fermé. Je l'ai retrouvé dans l'historique de mes recherches google.
Perso, je sais pas c'que \312\4 signifie. Si une âme charitable meilleur que moi en c système linux pouvait expliquer …
# Re-écriture du script
Posté par Cereal Killer . En réponse au message Comportement bizarre de redirection en ksh. Évalué à 1.
Pour info, finalement, j'ai juste ré-écrit le script de manière plus lisible.
Et, après avoir re-testé ce matin sur les 2 machines, j'ai à le même comportement :/ pt'être un truc lié au 27 Novembre ? :)
Quoiqu'il en soit, ce bout de truc ne marchait juste pas en ksh alors qu'il marche en bash. Il n'écrit rien, ni sur stdout, ni dans le fichier. Alors que le client utilise ce script depuis des années sans jamais s'en être rendu compte. C'est d'ailleurs pour ça que je l'ai ré-écris.
Ceci dis, par curiosité, si quelqu'un pouvait m’expliquer le pourquoi ça fonctionne en bash et pas en ksh … et éventuellement, qu'est-ce que ça fait exactement.
Pour moi, ça redirige la sortie standard dans un sous shell qui redirige sa sortie standard sur tee.
Le type utilisait ça pour mettre stdout et stderr dans un tee => echo plop 1> >(tee -a $LOG_OUT) 2> >(tee -a $LOG_ERR >&2).
[^] # Re: version de ksh
Posté par Cereal Killer . En réponse au message Comportement bizarre de redirection en ksh. Évalué à 0.
Non, malheureusement, c'est la même version de ksh, sur le même OS avec le même paquet installé de la même façon, avec le même ~/.kshrc :/
[^] # Re: t'as surement déja regardé mais bon:
Posté par Cereal Killer . En réponse au message Comportement bizarre de redirection en ksh. Évalué à 1.
Effectivement, déjà regardé et c'est pas ça.
[^] # Re: ssh lit le stdin
Posté par Cereal Killer . En réponse au message Tiens, là je vois pas.... Évalué à -2.
je croyais que ton problème était de lire une ligne entière …
Si ton soucis c'est que ta boucle sort à la première ligne, utilise ssh -n (man ssh). Et ta boucle ne calera plus à la première ligne.
Sylvain
[^] # Re: ssh lit le stdin
Posté par Cereal Killer . En réponse au message Tiens, là je vois pas.... Évalué à -5.
cat file | while read line;
do
echo $line
done
fonctionne aussi.
# \
Posté par Cereal Killer . En réponse au message point d'exclamation dans une variable. Évalué à 0.
$ largeur=1;hauteur=2! && echo "${largeur}x${hauteur}"
1x2!
$
# google toussa
Posté par Cereal Killer . En réponse au message Identification http certificat. Évalué à 3.
mots magiques : apache 2 way ssl
En gros, quand un utilisateur veut accéder à un Directory, Location ou File ou autre, tu lui dis qu'il doit présenter son certificat client.
On parle alors d'authentification SSL dans les 2 sens. (le premier sens est l'authentification du serveur auprès du client)
Il faut évidemment que le client "trust" le certificat du serveur et que le serveur "trust" le certificat du client.
Il me semble que les impots avait essayé de mettre ça en place pendant un temps, ou certaines banques (au moins hsbc).
C'est certainement la manière la plus propre pour faire ce que tu souhaites.
[^] # Re: banque de marché
Posté par Cereal Killer . En réponse au journal Linux en entreprise : votre retour ?. Évalué à 3.
Bon, finalement, les chiffres précédent sont faux parce qu’ils comptes les desk windows ...
En ne prenant que les serveurs, on arrive a :
12 000 unix.
13 000 windows.
Soit presque la moitié quand même.
# banque de marché
Posté par Cereal Killer . En réponse au journal Linux en entreprise : votre retour ?. Évalué à 3.
Ici dans une banque du coté des activités de marché, on à la louche 50 000 serveurs en tout dont 75% de windows et 25% d'unix.
Dans les 25% d'unix, plus de 70% des serveurs sont sous linux, le reste, c'est du solaris. (peut-être quelques vieux AIX, mais c'est pas significatif).
Comme distrib, c'est exclusivement du redhat.
En chiffre, ça fais à peu près :
35 000 windows
12 000 unix
dont
8000 linux
3500 solaris
Attention, il faut savoir que les linux sont bien souvent mutualisé. Donc plusieurs "services" (comprendre ça un peu comme un container) peuvent être installé sur le même OS.
Donc les chiffres ne représente que les OS installés, pas forcément leur volume d'utilisation. D'autant qu'une partie des windows ne sont utilisé qu'en cas de plan de secours (ils idle 99% de leur temps) alors que les unix ont une méthode plus propre de bascule en plan de secours.
# homebank
Posté par Cereal Killer . En réponse au message Logiciel de gestion de comptes en banques. Évalué à 1.
Faut juste prendre un peu de temps pour le paramètrer, mais pas besoin d'être comptable pour y arriver.
-> http://homebank.free.fr/
# vhost
Posté par Cereal Killer . En réponse au message Virtual Host avec apache2. Évalué à 2.
En gros, il existe 3 types de virtualhosts :
- basé sur l'ip
- basé sur le port
- basé sur le host header.
Pour l'ip, il te faut plusieurs @ip public sur ta machine, ce qui j'imagine n'est pas de le cas.
Pour le port, à priori, c'est pas ce que tu veux.
Ce qu'il t faut c'est sur le hostheader de ta requête http.
Donc tu déclares ton namevirtualhost tonip:80, tu déclares ton <VirtualHost tonip:80> et apache se débrouillera avec ce qu'il trouvera dans ServerName pour savoir que c'est bien ce site là qu'il doit fournir.
Si, par exemple, derrière il y a un tomcat ou autre serveur applicatif, tu peux éventuellement t'essayer aux proxypass sur un vhost binder sur la socket tonip:80 qui reécrira tout ce qui va et tout ce qui vient vers ton tomcat. Tu auras donc un apache en frontal et un tomcat derrière. Si c'est le cas, bind ton tomcat sur 127.0.0.1 et utilise le proxypass sur 127.0.0.1. Ton tomcat ne sera alors accessible que via ton apache.
Si c'est pas ce que tu veux, précise ta demande stp.
[^] # Re: remarques
Posté par Cereal Killer . En réponse à la dépêche De l'efficacité du fichier hosts.. Évalué à 4.
Même si cet article est relativement bien écrit et didactique, j'ai du mal a voir pour qui il est destiné. dslé
[^] # Re: Fausse bonne idée
Posté par Cereal Killer . En réponse à la dépêche De l'efficacité du fichier hosts.. Évalué à 10.
On dirait un article de quelqu'un qui découvre l'utilisation du fichier hosts, qui trouve ça formidable et qui se dit qui devrait partager sa découverte avec tout le monde en partageant son énorme fichier hosts.
Ce n'est ni bon pour le particulier, ni pour un entreprise (si petite soit elle) pour toute les raisons déjà relevée.
Comment une dépêche comme ça a pu passer, sérieusement ?
[^] # Re: remarques
Posté par Cereal Killer . En réponse à la dépêche De l'efficacité du fichier hosts.. Évalué à 0.
Pour moi 127.0.0.1 est fait pour ça. Aucun intérêt de mettre autre chose, si ce n'est se compliquer la vie inutilement.
[^] # Re: remarques
Posté par Cereal Killer . En réponse à la dépêche De l'efficacité du fichier hosts.. Évalué à 2.
# apache mod_proxy
Posté par Cereal Killer . En réponse au message redirection transparente de domaine. Évalué à 1.
En gros, avec mod_proxy et de l'url rewriting, tu fais a peu près tout ce que tu peux imaginer et même ce que t'imagines pas ;)
[^] # Re: Exploitabilité *réelle*
Posté par Cereal Killer . En réponse à la dépêche Faille locale dans les fonctions pipe_*_open() du noyau Linux. Évalué à 2.
C'est aussi valable sous *BSD ;)
Sans être un maniaque de la sécurité, il y a quelques règles très simple à mettre en place sur tout linux fraîchement installé :
- limité le nombre de services réseaux (ou pas) au maximum.
- sécurisé un minimum ces points d'entrées.
Après, utiliser/configurer iptables aux petits oignons sur un desktop, c'est plus un luxe que vraiment utile amha.
[^] # Re: laisse moi deviner
Posté par Cereal Killer . En réponse au message script qui fonctionne dans une console mais pas entièrement avec cron. Évalué à 1.
[^] # Re: Le pipe
Posté par Cereal Killer . En réponse au message exit qui exit pas. Évalué à 2.
Pour le problème dans son ensemble (ou presque), je suis dans un while getopts blablabla, ou toutes mes options font appel a des fonctions et certaines étaient récurentes.
Vu que j'aime pas les trucs récurents dans mes scripts, je les ai sortis du while et là, c le drame :)
Sinon, le pipe était pour rediriger l'ensemble de mon while dans un tee pour pouvoir laisser la log et afficher la sortie. J'ai trouver ça assez classe de gerer l'ensemble de mes sorties (stdout, stderr + log) avec un | tee $LOG bien placer, mais vu que ça fou le bordel ...
Maintenant que j'ai confirmation, va falloir ou choisir comment loger mieux (peut-être avec un fifo (merci wismerhill )) ou remettre mes fonctions redondante dans mes options de getopts.
En bref, je devrais m'en sortir, mais merci pour ta propositions :)
[^] # Re: http://www.chezmoicamarche.org/
Posté par Cereal Killer . En réponse au message exit qui exit pas. Évalué à 2.
j'essayerais de bricoler un truc avec un fifo, ça devrais faire l'affaire :)
[^] # Re: man bash
Posté par Cereal Killer . En réponse au message Dialecte inconnu. Évalué à 0.
http://tldp.org/LDP/abs/html/refcards.html#AEN21717
# o/*
Posté par Cereal Killer . En réponse au message [bash] bug dans mon script. Évalué à 2.
Du coup http://pastebin.com/m35421a2e
En gros, t'avais des = au lieu de == et des grep que j'ai changer par des grep -c. (man grep pour les détails).
A priori, ça marche.
[^] # Re: "Tout feedback/idée etc est le bienvenue"
Posté par Cereal Killer . En réponse au journal LinuxFr sur iPhone. Évalué à 10.
Je pense que s'il à fait cette applications, c'est qu'elle répond au moins à un de ses besoins, et s'il vient en parler, c'est pour voir si ça intéresse d'autres gens et si ces mêmes gens n'auraient pas des suggestions pour améliorer cette petite appli.