Re: [FRsAG] Présentation
On Tue, 26 Apr 2011 20:04:07 +0200, Julien Syx wrote: 2011/4/26 Stephane Dupille système dinformation de gestion de la production SNCF ... Côté techno, cest 100% java Bonjour, Je me suis permis de quoter juste ce quil faut (bien que nous sommes que mardi) : C'est bien :) Ah, SNCF et Java, tout ceci explique cela ;-) C'est bizzare, j'ai pas entendu parler d'une pénurie de RAM. Pourtant vu ce que ca risque de bouffer... "En raison d'un java.lang.OutOfMemoryError, le train 42 à destination de Plouville-les-ouailles arrivera avec un retard de 42 minutes" -- Julien Syx Links: -- [1] mailto:sdupi...@nospam.fr.eu.org ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Présentation
Julien Syx écrit : > Bonjour, Yop, >> système d'information de gestion de la production SNCF ... >> Côté techno, c'est 100% java > Je me suis permis de quoter juste ce qu'il faut (bien que nous sommes que > mardi) : > Ah, SNCF et Java, tout ceci explique cela ;-) Tu as coupé le mot « fret ». Parce que bon, on ne s'occupe pas du transport du bétail^H^H^H^Hvoyageurs. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Présentation
> C'est bizzare, j'ai pas entendu parler d'une pénurie de RAM. Pourtant > vu ce que ca risque de bouffer... Java a été développé par un marchand de RAM et CPU. Ça c'est vu. Puisqu'on n'est pas vendredi : quelle autre techno avons-nous pour développer une application native et portable ? .NET n'est pas portable mais aurait été une option. Et dans les arguments en faveur de java, on a JWS, qui marche très bien pour gérer les déploiements. > "En raison d'un java.lang.OutOfMemoryError, le train 42 à destination > de Plouville-les-ouailles arrivera avec un retard de 42 minutes" Pour le monde du fret, si chaque train avait un retard de 42 minutes, on serait content. Dans certains cas relativement courants, le retard se chiffre en jours... ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Présentation
On Wed, 27 Apr 2011 10:06:25 +0200, Stephane Dupille wrote: C'est bizzare, j'ai pas entendu parler d'une pénurie de RAM. Pourtant vu ce que ca risque de bouffer... Java a été développé par un marchand de RAM et CPU. Ça c'est vu. Puisqu'on n'est pas vendredi : quelle autre techno avons-nous pour développer une application native et portable ? .NET n'est pas portable mais aurait été une option. Euh... Bah moi tant que c'est portable entre les BSD et les Linux, ca me va :) Sinon, faut coder pour MultideskOS :) Et dans les arguments en faveur de java, on a JWS, qui marche très bien pour gérer les déploiements. "En raison d'un java.lang.OutOfMemoryError, le train 42 à destination de Plouville-les-ouailles arrivera avec un retard de 42 minutes" Pour le monde du fret, si chaque train avait un retard de 42 minutes, on serait content. Dans certains cas relativement courants, le retard se chiffre en jours... Faudrait dire ca aux voyageurs : "Mais madame, vous savez, vous seriez un sac de patates, ca serait 4 ou 5 jours de retard. Alors franchement, vous plaindre pour 3h..." ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Présentation
Julien Gormotte écrit : > Faudrait dire ca aux voyageurs : > "Mais madame, vous savez, vous seriez un sac de patates, ca serait 4 > ou 5 jours de retard. Alors franchement, vous plaindre pour 3h..." J'ai déjà été la cause de quelques grèves : « tu sais le bordel de la semaine dernière ? Ben c'était moi ». Ça fait toujours son petit effet dans les diners. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Présentation
On Wed, 27 Apr 2011 11:12:01 +0200, Stephane Dupille wrote: Julien Gormotte écrit : Faudrait dire ca aux voyageurs : "Mais madame, vous savez, vous seriez un sac de patates, ca serait 4 ou 5 jours de retard. Alors franchement, vous plaindre pour 3h..." J'ai déjà été la cause de quelques grèves : « tu sais le bordel de la semaine dernière ? Ben c'était moi ». Ça fait toujours son petit effet dans les diners. Ouais, mais faut se méfier, si un des invités a perdu un contrat ou raté un entretien d'embauche, après t'es obligé d'enlever la fourchette de ton œil... ___ Liste de diffusion du FRsAG http://www.frsag.org/ ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Inspecter le flux HTTP
Bonjour la liste, Afin de pister un bug bien velu, on cherche à inspecter le flux réseau entre un client et nous. Problème, on a un frontal qui fait du SSL et rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs d'application. Un moyen de trouver les requêtes que fait le client est de faire ça : ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir d'option pour ceci dans ngrep. Auriez-vous des pistes à me suggérer (on peut très difficilement tout enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi impossible du fait de sa taille) ? Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 et ensuite de décoder le HTTPS ? (avec wireshark ?) Merci de votre aide ! Valentin ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Le 27 avril 2011 11:37, Valentin Surrel a écrit : > Bonjour la liste, Salut, > Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 > et ensuite de décoder le HTTPS ? (avec wireshark ?) Oui : - http://wiki.wireshark.org/SSL - http://htluo.blogspot.com/2009/01/decrypt-https-traffic-with-wireshark.html - http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark -- Yohann L. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Valentin, Le 27 avril 2011 11:37, Valentin Surrel a écrit : > Bonjour la liste, > > Afin de pister un bug bien velu, on cherche à inspecter le flux réseau > entre un client et nous. Problème, on a un frontal qui fait du SSL et > rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs > d'application. Donc tu as l'IP du client en amont du reverse proxy, puis tu as le marqueur entre le RP et le serveur, mais en retour du serveur, tu n'as aucun moyen de distinguer la destination de la réponse à part le fait que le retour se fasse sur la même session TCP que le paquet marqué en entrée, c'est bien ça ? tcpdump sait filtrer de façon assez avancée, mais pas en statefull malheureusement. Donc à part un filtrage à posteriori d'un .pcap gigantesque, ça ne parait pas être une option. Est ce que tu as un moyen d'altérer le code fonctionnant sur le serveur applicatif pour rendre le header persistant et l'inclure dans la réponse ? -- Jérôme Nicolle 06 19 31 27 14 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Si tu as la main sur le client, tu peux voir la réponse avec des plugin comme live http headers pour firefox ou le bookmarklet headers pour chrome. Maintenant, si tu sais que l'IP du client est 1.2.3.4, tu peux filtrer dessus... tcpdump -A -s2048 host 1.2.3.4 devrait te montrer les headers renvoyés à ce client là. Je ne sais pas quelle techno tu as, mais tu peux aussi mettre le module rpxy en debug... Quel est le bug déjà ? 2011/4/27 Valentin Surrel : > Bonjour la liste, > > Afin de pister un bug bien velu, on cherche à inspecter le flux réseau > entre un client et nous. Problème, on a un frontal qui fait du SSL et > rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs > d'application. > > Un moyen de trouver les requêtes que fait le client est de faire ça : > > ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 > > 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer > la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir > d'option pour ceci dans ngrep. > > Auriez-vous des pistes à me suggérer (on peut très difficilement tout > enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi > impossible du fait de sa taille) ? > > Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 > et ensuite de décoder le HTTPS ? (avec wireshark ?) > > Merci de votre aide ! > > Valentin > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
A grand coup de tshark, tu dois pouvoir filtrer ca correctement : http://www.wireshark.org/docs/dfref/h/http.html Par contre il te faudra sans doute modifier le nom du header pour le standard de facto X-Forwarded-For, car je ne vois pas comment le spécifier autrement. C'est quoi le bug bien velu sinon ? Hervé. On Wed, 27 Apr 2011 11:37:53 +0200 Valentin Surrel wrote: > Bonjour la liste, > > Afin de pister un bug bien velu, on cherche à inspecter le flux réseau > entre un client et nous. Problème, on a un frontal qui fait du SSL et > rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs > d'application. > > Un moyen de trouver les requêtes que fait le client est de faire ça : > > ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 > > 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas > tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y > avoir d'option pour ceci dans ngrep. > > Auriez-vous des pistes à me suggérer (on peut très difficilement tout > enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi > impossible du fait de sa taille) ? > > Est-il possible de faire le tcpdump en amont du frontal sur l'IP > 1.2.3.4 et ensuite de décoder le HTTPS ? (avec wireshark ?) > > Merci de votre aide ! > > Valentin > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ -- Hervé COMMOWICK, EXOSEC (http://www.exosec.fr/) ZAC des Metz - 3 Rue du petit robinson - 78350 JOUY EN JOSAS Tel: +33 1 30 67 60 65 - Fax: +33 1 75 43 40 70 mailto:hcommow...@exosec.fr ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Je pense à un autre point, avec un peu de chance, il y a un cookie dans l'histoire qui permette de suivre la session... ? 2011/4/27 Valentin Surrel : > Bonjour la liste, > > Afin de pister un bug bien velu, on cherche à inspecter le flux réseau > entre un client et nous. Problème, on a un frontal qui fait du SSL et > rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs > d'application. > > Un moyen de trouver les requêtes que fait le client est de faire ça : > > ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 > > 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer > la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir > d'option pour ceci dans ngrep. > > Auriez-vous des pistes à me suggérer (on peut très difficilement tout > enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi > impossible du fait de sa taille) ? > > Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 > et ensuite de décoder le HTTPS ? (avec wireshark ?) > > Merci de votre aide ! > > Valentin > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Deux clients (utilisant les deux Firefox 3.6.16 ; un sous Mac un sous Win) "perdent" leur session chez nous très régulièrement (au bout de quelques requêtes, à moins de quelques secondes du login). Jamais sur le même appel, cela semble relativement aléatoire. Je cherche donc déjà à tracer tout les headers HTTP dans les deux sens pour voir si : - le cookie de session est toujours bien retourné par le client (et son contenu) - si on aurait pas mis du delete cookie dans une réponse par erreur En gros déjà isoler si c'est un problème coté client ou coté applicatif. On n'a pas la main sur les clients, c'est du genre client lambda. Pour la petite histoire du X-Forwarded-For, c'est pas toujours idéal parce qu'il est trafiqué à chaque étage des reverse-proxy et chacun rajoute sa merde (entre autre les proxys de sorties des grosses entreprises), notre frontal ajoute un X-Real-IP pour avoir simplement l'IP d'où vient la requête sans se prendre la tête. Le frontal est un nginx, je vais voir s'il est possible de lui faire dumper les headers dans les deux sens, mais je vais aussi regarder en prioriter le tcpdump en amont du SSL et décrypter le flux. Le 27/04/2011 12:04, Hervé COMMOWICK a écrit : > A grand coup de tshark, tu dois pouvoir filtrer ca correctement : > http://www.wireshark.org/docs/dfref/h/http.html > > Par contre il te faudra sans doute modifier le nom du header pour le > standard de facto X-Forwarded-For, car je ne vois pas comment le > spécifier autrement. > > C'est quoi le bug bien velu sinon ? > > Hervé. > > On Wed, 27 Apr 2011 11:37:53 +0200 > Valentin Surrel wrote: > >> Bonjour la liste, >> >> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau >> entre un client et nous. Problème, on a un frontal qui fait du SSL et >> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs >> d'application. >> >> Un moyen de trouver les requêtes que fait le client est de faire ça : >> >> ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 >> >> 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas >> tracer la réponse HTTP renvoyé par le serveur. Il ne semble pas y >> avoir d'option pour ceci dans ngrep. >> >> Auriez-vous des pistes à me suggérer (on peut très difficilement tout >> enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi >> impossible du fait de sa taille) ? >> >> Est-il possible de faire le tcpdump en amont du frontal sur l'IP >> 1.2.3.4 et ensuite de décoder le HTTPS ? (avec wireshark ?) >> >> Merci de votre aide ! >> >> Valentin >> ___ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ > > > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Le 27/04/2011 12:11, Steven Le Roux a écrit : > Je pense à un autre point, avec un peu de chance, il y a un cookie > dans l'histoire qui permette de suivre la session... ? Oui et justement je cherche à trouver s'il est bien tout le temps là et quel est son contenu. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Il y n'y a pas un nofailover à off (conf apache) en cas de non dispo d'un backend ? (ce qui casserait effectivement volontairement la session) Ne vois-tu pas d'indipo des backend dans les logs ? 2011/4/27 Valentin Surrel : > Le 27/04/2011 12:11, Steven Le Roux a écrit : >> Je pense à un autre point, avec un peu de chance, il y a un cookie >> dans l'histoire qui permette de suivre la session... ? > > Oui et justement je cherche à trouver s'il est bien tout le temps là et > quel est son contenu. > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Non je suis bien sur qu'il n'y a aucune indispo backend (d'autant plus que ca n'arrive toujours qu'aux deux même clients et que pendant ce temps là les autres clients n'ont aucun soucis). Je vais préparer le tcpdump du ssl et attendre que les deux clients problématiques se reconnectent. Le 27/04/2011 12:19, Steven Le Roux a écrit : > Il y n'y a pas un nofailover à off (conf apache) en cas de non dispo > d'un backend ? (ce qui casserait effectivement volontairement la > session) > > Ne vois-tu pas d'indipo des backend dans les logs ? > > > > 2011/4/27 Valentin Surrel : >> Le 27/04/2011 12:11, Steven Le Roux a écrit : >>> Je pense à un autre point, avec un peu de chance, il y a un cookie >>> dans l'histoire qui permette de suivre la session... ? >> >> Oui et justement je cherche à trouver s'il est bien tout le temps là et >> quel est son contenu. >> ___ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ >> > > > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Le 27/04/2011 11:47, Yohann Lepage a écrit : > Oui : > - http://wiki.wireshark.org/SSL > - http://htluo.blogspot.com/2009/01/decrypt-https-traffic-with-wireshark.html > - http://blogs.sun.com/beuchelt/entry/decrypting_ssl_traffic_with_wireshark J'essaye actuellement cete piste, pour l'instant ca n'arrive pas à décoder correctement le SSL. Alors que la clé privée est bien chargée. Je regarde un peu plus en détail ; mais je ne comprends pas le "no decoder available" alors que j'ai bien indiqué dans les prefs SSL sur port 443 avec cette IP => http FYI le debug log du decodage SSL : ssl_init keys string: 188.165.227.167,443,http,/home/valentin/Bureau/private.key ssl_init found host entry 188.165.227.167,443,http,/home/valentin/Bureau/private.key ssl_init addr '188.165.227.167' port '443' filename '/home/valentin/Bureau/private.key' password(only for p12 file) '(null)' Private key imported: KeyID c1:d1:24:7e:61:14:2c:7e:ee:de:01:1f:81:e6:49:09:... ssl_init private key file /home/valentin/Bureau/private.key successfully loaded association_add TCP port 443 protocol http handle 0x7fdfd8e72c50 dissect_ssl enter frame #15 (first time) ssl_session_init: initializing ptr 0x7fdfba3e0028 size 672 conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46731 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01 dissect_ssl enter frame #17 (first time) conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_ssl3_hnd_hello_common found SERVER RANDOM -> state 0x13 dissect_ssl3_hnd_srv_hello can't find cipher suite 0x39 record: offset = 86, reported_length_remaining = 1362 need_desegmentation: offset = 86, reported_length_remaining = 1362 dissect_ssl enter frame #18 (first time) conversation = 0x7fdfba3de8b8, ssl_session = 0x7fdfba3e0028 record: offset = 0, reported_length_remaining = 2759 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 2343, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 11 offset 5 length 2339 bytes, remaining 2348 record: offset = 2348, reported_length_remaining = 411 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 397, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 12 offset 2353 length 393 bytes, remaining 2750 record: offset = 2750, reported_length_remaining = 9 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 4, ssl state 0x13 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 14 offset 2755 length 0 bytes, remaining 2759 dissect_ssl enter frame #20 (first time) ssl_session_init: initializing ptr 0x7fdfba3e0790 size 672 conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 419 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 414, ssl state 0x00 association_find: TCP port 46732 found (nil) packet_from_server: is from server - FALSE decrypt_ssl3_record: using client decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 1 offset 5 length 410 bytes, remaining 419 packet_from_server: is from server - FALSE ssl_find_private_key server 188.165.227.167:443 dissect_ssl3_hnd_hello_common found CLIENT RANDOM -> state 0x01 dissect_ssl enter frame #22 (first time) conversation = 0x7fdfba3dec50, ssl_session = 0x7fdfba3e0790 record: offset = 0, reported_length_remaining = 1448 dissect_ssl3_record found version 0x0301 -> state 0x11 dissect_ssl3_record: content_type 22 decrypt_ssl3_record: app_data len 81, ssl state 0x11 packet_from_server: is from server - TRUE decrypt_ssl3_record: using server decoder decrypt_ssl3_record: no decoder available dissect_ssl3_handshake iteration 1 type 2 offset 5 length 77 bytes, remaining 86 dissect_
[FRsAG] Hosting control panel OpenSource
Bonjour, Je recherche une interface de gestion OpenSource pour gérer quelques sites web et comptes FTP. Est-ce que vous avez des avis ou des retours d'expérience sur ces outils? Mes besoins sont principalement : gestion des vhosts apache, suphp des comptes FTP. Évidemment toutes autres fonctions peuvent être intéressantes. Pour l'instant j'ai retenu : DTC : http://www.gplhost.com/software-dtc.html VHCS : http://www.vhcs.net/ VHFFS : http://www.vhffs.org/overview ps : si vous en connaissez un qui gère les mails avec cyrus+ldap je suis intéressé! -- Cordialement, Julien Bérard probeSys spécialiste GNU/Linux Tèl: 09-74-76-47-86 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Hosting control panel OpenSource
Le 27 avril 2011 16:25, Julien Bérard a écrit : > Bonjour, > ps : si vous en connaissez un qui gère les mails avec cyrus+ldap je suis > intéressé! GOsa²/FusionDirectory ? -- Gonéri Le Bouder ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Hosting control panel OpenSource
On 27/04/2011 16:41, Gonéri Le Bouder wrote: Le 27 avril 2011 16:25, Julien Bérard a écrit : Bonjour, ps : si vous en connaissez un qui gère les mails avec cyrus+ldap je suis intéressé! GOsa²/FusionDirectory ? Pour la partie cyrus/ldap je suis d'accord, mais pas la partie apache vhost, pour le ftp oui si je stocke mes utilisateurs dans ldap. -- Cordialement, Julien Bérard probeSys spécialiste GNU/Linux Tèl: 09-74-76-47-86 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Hosting control panel OpenSource
http://www.ispconfig.org/ est très bien foutu avec en plus une interface moins usine à gaz que la plupart des autres solus à mon goût... - Mail original - > De: "Julien Bérard" > À: frsag@frsag.org > Envoyé: Mercredi 27 Avril 2011 16:25:10 > Objet: [FRsAG] Hosting control panel OpenSource > > Bonjour, > Je recherche une interface de gestion OpenSource pour gérer quelques > sites web et comptes FTP. > > Est-ce que vous avez des avis ou des retours d'expérience sur ces > outils? > > Mes besoins sont principalement : gestion des vhosts apache, suphp > des > comptes FTP. > Évidemment toutes autres fonctions peuvent être intéressantes. > > Pour l'instant j'ai retenu : > DTC : http://www.gplhost.com/software-dtc.html > VHCS : http://www.vhcs.net/ > VHFFS : http://www.vhffs.org/overview > > ps : si vous en connaissez un qui gère les mails avec cyrus+ldap je > suis > intéressé! > > -- > Cordialement, > > Julien Bérard > > probeSys spécialiste GNU/Linux > Tèl: 09-74-76-47-86 > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Hosting control panel OpenSource
Il existe aussi Ispconfig dans le même genre d'idée. Le 27 avr. 2011 à 16:25, Julien Bérard a écrit : > Bonjour, > Je recherche une interface de gestion OpenSource pour gérer quelques sites > web et comptes FTP. > > Est-ce que vous avez des avis ou des retours d'expérience sur ces outils? > > Mes besoins sont principalement : gestion des vhosts apache, suphp des > comptes FTP. > Évidemment toutes autres fonctions peuvent être intéressantes. > > Pour l'instant j'ai retenu : > DTC : http://www.gplhost.com/software-dtc.html > VHCS : http://www.vhcs.net/ > VHFFS : http://www.vhffs.org/overview > > ps : si vous en connaissez un qui gère les mails avec cyrus+ldap je suis > intéressé! > > -- > Cordialement, > > Julien Bérard > > probeSys spécialiste GNU/Linux > Tèl: 09-74-76-47-86 > > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ -- Cédric Polomack http://www.secresys.fr ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Hosting control panel OpenSource
Oups. J'ai fait doublon ... Le 27 avr. 2011 à 16:50, Christophe BAILLON a écrit : > http://www.ispconfig.org/ est très bien foutu avec en plus une interface > moins usine à gaz que la plupart des autres solus à mon goût... > > - Mail original - >> De: "Julien Bérard" >> À: frsag@frsag.org >> Envoyé: Mercredi 27 Avril 2011 16:25:10 >> Objet: [FRsAG] Hosting control panel OpenSource >> >> Bonjour, >> Je recherche une interface de gestion OpenSource pour gérer quelques >> sites web et comptes FTP. >> >> Est-ce que vous avez des avis ou des retours d'expérience sur ces >> outils? >> >> Mes besoins sont principalement : gestion des vhosts apache, suphp >> des >> comptes FTP. >> Évidemment toutes autres fonctions peuvent être intéressantes. >> >> Pour l'instant j'ai retenu : >> DTC : http://www.gplhost.com/software-dtc.html >> VHCS : http://www.vhcs.net/ >> VHFFS : http://www.vhffs.org/overview >> >> ps : si vous en connaissez un qui gère les mails avec cyrus+ldap je >> suis >> intéressé! >> >> -- >> Cordialement, >> >> Julien Bérard >> >> probeSys spécialiste GNU/Linux >> Tèl: 09-74-76-47-86 >> >> ___ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ >> > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ -- Cédric Polomack http://www.secresys.fr ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Hosting control panel OpenSource
+1 Bon outil et moins intrusif dans les configs que la plupart des outils du marché. My 2 cents. Benjamin. Le 27 avril 2011 16:50, Christophe BAILLON a écrit : > http://www.ispconfig.org/ est très bien foutu avec en plus une interface > moins usine à gaz que la plupart des autres solus à mon goût... > > ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Java et portabilité (was: Présentation)
On Wed, 27 Apr 2011 10:06:25 +0200, Stephane Dupille wrote: Puisqu'on n'est pas vendredi : quelle autre techno avons-nous pour développer une application native et portable ? .NET n'est pas portable mais aurait été une option. Quelles sont tes définitions de : * natif ? Une application qui tourne sur la JVM n'a rien de "natif" pour moi. Dans pas mal de contextes, "natif" est même synonyme de "pas Java"... * portable ? Une application Java est (au mieux) portable sur les plate-formes où il existe une implémentation de la JVM. Une application en Python est (au mieux) portable sur celles où il existe une implémentation de Python. Une application .NET peut être relativement portable si elle tourne avec Mono... -- Pierre Chapuis ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité (was: Présentation)
Le Wed, Apr 27, 2011 at 05:22:24PM +0200, Pierre Chapuis [catw...@archlinux.us] a écrit: >plate-formes où il existe une implémentation de la JVM. Une >application en Python est (au mieux) portable sur celles où il >existe une implémentation de Python. Une application .NET est (au mieux) portable sur les plateformes où existent une implémeentation du CLR et des classes qui vont autour, notamment si on veut « afficher » des trucs. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Question juridique concernant l'accès aux données mobiles
Bonjour à tous, Je me tourne vers vous tout en sachant que cela ne relève pas forcément de cette liste! Je cherche des informations légales concernant l'accès possible à un terminal mobile personnel utilisé dans le cadre professionnel. Je m'explique : Une entreprise souhaite déployer des accès mobiles pour certains de ses employés, cependant elle ne souhaite pas investir dans une flotte mobile... Elle voudrait profiter des smart phones personnels des employés ! Elle va devoir procéder à la sécurisation des terminaux, et prévoir une procédure d'effacement des données et/ou du terminal en cas de perte ou de vol! Ma question est la suivante : Y a-t-il des limites juridiques à ça ? Des textes de loi empêchent-ils ce genre de procédés ? D'avance merci. Benjamin ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité (was: Présentation)
2011/4/27 Pierre Chapuis : > On Wed, 27 Apr 2011 10:06:25 +0200, Stephane Dupille wrote: > >> Puisqu'on n'est pas vendredi : quelle autre techno avons-nous pour >> développer une application native et portable ? .NET n'est pas >> portable mais aurait été une option. Faisable en C/Python, avec un toolkit existant sur les plateformes, soit Qt/GTK, mais à chier, donc EFL (bcp mieux). Dépend plus largement des binding de chaque toolkit pour le langage en question, qui lui a des chances d'être déjà porté. Java pour ce qui est graphique c'est pas top... ou alors tu fais du GWT pour générer du javascript. Mais si tu parles de "natif", j'imagine que ça tourne sur le client lui même. Selon son dimensionnement, les EFL peuvent être une excellente solution car taillé pour l'embarqué le plus léger (ereader/frigo/téléphones/solution domotique (comme Calaos) ) En plus, elles sont stables et releasée (avant duke nukem forever !! ) > > Quelles sont tes définitions de : > > * natif ? Une application qui tourne sur la JVM n'a rien de "natif" > pour moi. Dans pas mal de contextes, "natif" est même synonyme de > "pas Java"... > > * portable ? Une application Java est (au mieux) portable sur les > plate-formes où il existe une implémentation de la JVM. Une > application en Python est (au mieux) portable sur celles où il > existe une implémentation de Python. Une application .NET peut > être relativement portable si elle tourne avec Mono... > > -- > Pierre Chapuis > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité
Pierre Chapuis écrit : > Quelles sont tes définitions de : > * natif ? Une application qui tourne sur la JVM n'a rien de "natif" > pour moi. Dans pas mal de contextes, "natif" est même synonyme de > "pas Java"... Oui, abus de langage de ma part. J'entends par appli native une appli donc le code est executé sur le client. Par opposition aux clients légers qui s'executent sur le serveur et/ou dans un navigateur. Ce n'est pas natif dans le sens où on produit du code directement compilé pour la plateforme cible. > * portable ? Une application Java est (au mieux) portable sur les > plate-formes où il existe une implémentation de la JVM. Une > application en Python est (au mieux) portable sur celles où il > existe une implémentation de Python. Une application .NET peut > être relativement portable si elle tourne avec Mono... Comme tout ce qui est interprété, oui, c'est portable tant que l'interpréteur est porté. Avec néanmoins certaines limites : certaines implémentations sur certains environnements limitent la portabilité. Et c'est peut-être encore un abus de langage de ma part, mais tout ce qui nécessite une JVM est par définition interprété. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité
Steven Le Roux écrit : > Java pour ce qui est graphique c'est pas top... ou alors tu fais du > GWT pour générer du javascript. Mais si tu parles de "natif", > j'imagine que ça tourne sur le client lui même. Oui, ça tourne sur le client lui-même. Et on utilise Swing. Et ça marche plutôt pas mal. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité (was: Présentation)
On Wed, 27 Apr 2011 17:49:31 +0200, Steven Le Roux wrote: Faisable en C/Python, avec un toolkit existant sur les plateformes, soit Qt/GTK, mais à chier, donc EFL (bcp mieux). Dépend plus largement des binding de chaque toolkit pour le langage en question, qui lui a des chances d'être déjà porté. J'aurais dit Python/wxPython mais je ne vais pas rentrer dans un troll entre les toolkits graphiques : de toute façon ça devrait être mieux que Swing. -- Pierre Chapuis ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité
Pierre Chapuis écrit : > mais je ne vais pas rentrer dans un troll entre les toolkits > graphiques Puis : > de toute façon ça devrait être mieux que Swing. Today is friday ! ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Java et portabilité
On Wed, 27 Apr 2011 18:08:52 +0200, Stephane Dupille wrote: Pierre Chapuis écrit : mais je ne vais pas rentrer dans un troll entre les toolkits graphiques Puis : de toute façon ça devrait être mieux que Swing. Today is friday ! Oops, pas assez discret :) -- Pierre Chapuis ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
Bonsoir, On 27/04/2011 11:37, Valentin Surrel wrote: > Bonjour la liste, > > Afin de pister un bug bien velu, on cherche à inspecter le flux réseau > entre un client et nous. Problème, on a un frontal qui fait du SSL et > rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs > d'application. > > Un moyen de trouver les requêtes que fait le client est de faire ça : > > ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 > > 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer > la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir > d'option pour ceci dans ngrep. > > Auriez-vous des pistes à me suggérer (on peut très difficilement tout > enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi > impossible du fait de sa taille) ? > > Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 > et ensuite de décoder le HTTPS ? (avec wireshark ?) Je suppose que le cookie (de session ?) est généré (et donc géré) par le(s) serveur(s) applicatif(s) et non par le reverse ? 1. Est-il envisageable de faire sauter le SSL entre le reverse et le serveur applicatif ? Ce qui simplifierait l'écoute réseau. 2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le flux est bien en SSL, est-il envisageable de forcer l'utilisation du chiffrement null entre le reverse et le serveur applicatif ? Le flux circulerait alors en clair bien qu'en SSL (négo toussa) ce qui simplifierait l'écoute réseau. 3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement juste pour ces utilisateurs là. 4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un peu de ménage dans les headers, voire ajouterait ces propres cookies (de mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la requête pourrait être débarrassée du cookie de session. 5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé. Mes 2 cents, JB ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
2011/4/27 Jean Baptiste FAVRE : > Bonsoir, > > On 27/04/2011 11:37, Valentin Surrel wrote: >> Bonjour la liste, >> >> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau >> entre un client et nous. Problème, on a un frontal qui fait du SSL et >> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs >> d'application. >> >> Un moyen de trouver les requêtes que fait le client est de faire ça : >> >> ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 >> >> 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer >> la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir >> d'option pour ceci dans ngrep. >> >> Auriez-vous des pistes à me suggérer (on peut très difficilement tout >> enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi >> impossible du fait de sa taille) ? >> >> Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 >> et ensuite de décoder le HTTPS ? (avec wireshark ?) > > Je suppose que le cookie (de session ?) est généré (et donc géré) par > le(s) serveur(s) applicatif(s) et non par le reverse ? > > 1. Est-il envisageable de faire sauter le SSL entre le reverse et le > serveur applicatif ? Ce qui simplifierait l'écoute réseau. > > 2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le > flux est bien en SSL, est-il envisageable de forcer l'utilisation du > chiffrement null entre le reverse et le serveur applicatif ? Le flux > circulerait alors en clair bien qu'en SSL (négo toussa) ce qui > simplifierait l'écoute réseau. > > 3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement > juste pour ces utilisateurs là. > > 4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un > peu de ménage dans les headers, voire ajouterait ces propres cookies (de > mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la > requête pourrait être débarrassée du cookie de session. Pour rebondir là dessus, même si leur proxy est niquel, puisque vous récupéré l'ip par laquelle il vient, (X-REAL-IP), est-ce que ce n'est pas votre serveur applicatif qui casse la session si l'ip change au cours de la session ? Ces utilisateurs sont peut être derriere un proxy qui load balancent deux accès internet... du coup l'ip peut changer une requete sur deux pour ceux là. > > 5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il > possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise > le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé. > > Mes 2 cents, > JB > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/ > -- Steven Le Roux Jabber-ID : ste...@jabber.fr 0x39494CCB 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Inspecter le flux HTTP
+1, j'avais pas pensé à celle-là tient ;) M'enfin, bloquer la session sur 1 IP (avec le roaming 3G toussa), faut être... enfin bon, bref :p JB On 27/04/2011 23:29, Steven Le Roux wrote: > 2011/4/27 Jean Baptiste FAVRE : >> Bonsoir, >> >> On 27/04/2011 11:37, Valentin Surrel wrote: >>> Bonjour la liste, >>> >>> Afin de pister un bug bien velu, on cherche à inspecter le flux réseau >>> entre un client et nous. Problème, on a un frontal qui fait du SSL et >>> rajoute un X-Real-IP header avant de reverse-proxy sur les serveurs >>> d'application. >>> >>> Un moyen de trouver les requêtes que fait le client est de faire ça : >>> >>> ngrep -d lo -q 'X-Real-IP: 1.2.3.4' -W byline port 7541 >>> >>> 1.2.3.4 étant l'IP du client. Le problème est que je ne peux pas tracer >>> la réponse HTTP renvoyé par le serveur. Il ne semble pas y avoir >>> d'option pour ceci dans ngrep. >>> >>> Auriez-vous des pistes à me suggérer (on peut très difficilement tout >>> enregistrer avec tcpdump, l'exploitation du fichier obtenu est quasi >>> impossible du fait de sa taille) ? >>> >>> Est-il possible de faire le tcpdump en amont du frontal sur l'IP 1.2.3.4 >>> et ensuite de décoder le HTTPS ? (avec wireshark ?) >> >> Je suppose que le cookie (de session ?) est généré (et donc géré) par >> le(s) serveur(s) applicatif(s) et non par le reverse ? >> >> 1. Est-il envisageable de faire sauter le SSL entre le reverse et le >> serveur applicatif ? Ce qui simplifierait l'écoute réseau. >> >> 2. Sinon, cas à la con où l'applicatif se préoccupe de vérifier que le >> flux est bien en SSL, est-il envisageable de forcer l'utilisation du >> chiffrement null entre le reverse et le serveur applicatif ? Le flux >> circulerait alors en clair bien qu'en SSL (négo toussa) ce qui >> simplifierait l'écoute réseau. >> >> 3. Passer le(s) serveur(s) applicatif(s) en mode debug, éventuellement >> juste pour ces utilisateurs là. >> >> 4. Ces clients sont-ils derrière un proxy ? Celui-ci ne ferait-il pas un >> peu de ménage dans les headers, voire ajouterait ces propres cookies (de >> mémoire, il ne peut y en avoir plus de 4 par requête. Du coup, la >> requête pourrait être débarrassée du cookie de session. > > Pour rebondir là dessus, même si leur proxy est niquel, puisque vous > récupéré l'ip par laquelle il vient, (X-REAL-IP), est-ce que ce n'est > pas votre serveur applicatif qui casse la session si l'ip change au > cours de la session ? Ces utilisateurs sont peut être derriere un > proxy qui load balancent deux accès internet... du coup l'ip peut > changer une requete sur deux pour ceux là. > > >> >> 5. Dérivé du précédent. Si les clients sont derrière un proxy, est-il >> possible que celui-ci, s'il ajoute son(es) propre(s) cookie(s) utilise >> le même nom de cookie(s) ? Du coup, l'ID de session serait remplacé. >> >> Mes 2 cents, >> JB >> ___ >> Liste de diffusion du FRsAG >> http://www.frsag.org/ >> > > > ___ Liste de diffusion du FRsAG http://www.frsag.org/
