nodens a écrit 569 commentaires

Celui dans ports.conf devrait effectivement suffire. A tout hasard, tu peux essayer de le mettre dans un fichier à part dans conf.d/ pour être sûr que ce n'est pas une histoire d'ordre.

Sinon apache2ctl -S, une reprise de la conf complète et un loglevel debug+la lecture des logs peuvent t'aider à trouver ce qui ne va pas dans ta conf. Généralement c'est un truc bête...

essentiellement, c'est l'absence de CalDav / Groupdav (prévu depuis longtemps, mais pas encore utilisable).
Ça fait que pour synchroniser un calendrier on est obligé de tout synchroniser. Si on a un gros calendrier (disons 10 évenement/semaine sur plus d'un an), c'est inutilisable, on passe plus de temps à synchroniser qu'à afficher le calendrier dans un autre client

Des petits bugs agaçant, comme la gestion des catégories, ou la compatibilité avec Thunderbird qui me pose souci. Ils n'implémentent pas tout à fait les mêmes éléments de la norme ICS, ce qui fait qu'il est impossible de positionner une alarme avec Thunderbird (kronolith la détruit). La synchro "casse" parfois sans qu'on sache pourquoi (et il faut reparamétrer thunderbird, même si c'est un bug de thunderbird ça n'arrive pas avec une autre implémentation.

Enfin du point de vue de l'interface, les utilisateurs ont généralement du mal. Moi ça me va, mais si on compare à ce qu'on voit dans OBM ou dans Cosmo / Chandler, il n'y a pas photo. Et comme on ne peut pas créer d'alarme à partir de thunderbird, les gens sont obligés d'utiliser l'interface web, et pas juste quand ils veulent partager leur calendrier.

Alors, pour la première question : il y a plusieurs méthodes, qui passent toutes par l'emploi d'un module spécifique.

Ceux qui me viennent à l'esprit sont mod_perl (configuration dynamique en perl, entre autres), et plus simple mais moins souple, mod_vhost_alias [1].

Pour ton deuxième problème, je dirais qu'il te manque une directive NameVirtualHost [2].
apachectl -S peut t'aider.

Cela dit, je ne vois pas pourquoi tu fais 2 vhosts différents, mais je suppose que les blocs ne sont pas complets (en tout cas si l'un des deux est une redirection sur l'autre, la directive DocumentRoot est superflue).

[1] http://httpd.apache.org/docs/2.2/mod/mod_vhost_alias.html
[2] http://httpd.apache.org/docs/2.2/mod/core.html#namevirtualho(...)

J'utilise le .bashrc pour lancer, effectivement, des commandes qui doivent être à jour à chaque instance du shell. Des truc fondamentaux et indispensables comme fortune, par exemple.

J'y mets aussi, plus sérieusement, tout ce que je risque de changer de temps en temps (pas besoin de se relogguer).

Enfin, j'ai tendance à inclure d'autres fichiers dans mon .bashrc : si ils sont présent, j'inclus .bash_functions et .bash_aliases. Je réserve le .bashrc aux variables d'environnement, et aux aliases / fonctions que j'utilise partout (je distribue mon .bashrc sur plusieurs machines).

Chez nous, on utilise cyrus imapd, (en mode murder), un ldap (qui sert à beaucoup d'autres choses que les mails, répliqué dans tous les sens avec moult overlays...) sendmail (et mimedefang...) et tout le tralala.

Pour le moment, on utilise une version modifiée de squirrelmail, et à plus petite échelle, Horde. Horde est un bon produit, modulaire, dynamique, ouvert, bien écrit et tout ce qu'on veut... Mais au niveau calendrier etc il est encore un peu limite (meme si il est très bien pour le support imap, et ce qu'il y a autour, allant jusqu'à gérer les ACL, l'intégration de l'annuaire, sieve, etc).

Le défault des solutions tout intégré à la Zimbra ou Citadel est qu'ils forcent les gens à utiliser leur solution de stockage pop/imap (quand ce n'est pas carrément le MTA). Ou à ne pas les utiliser du tout ;-)

On n'a aucune envie de lacher cyrus, ni sendmail. Ils font très bien leur boulot et ça serait compliqué de faire la même chose avec d'autres produits (Inutile de me soutenir le contraire, sieve, le support des groupes LDAP, murder, mimedefang, tout ça c'est quand même des solutions bien spécifique à cyrus et sendmail, il y a des alternatives chez la concurrence mais bon, if it ain't broken, don't fix it, comme on dit). Sans parler du fait qu'on a investi pas mal de temps dans cette plateforme, qu'on a développé ou intégré des solutions autour, etc.

OBM n'a pas l'air dans ce cas, d'après ce que je lis même si ça a plutôt l'air basé sur postfix pour la partie MTA, rien n'a l'air d'empêcher d'en utiliser un autre. Par contre je n'ai pas trouvé d'info claire au niveau de l'annuaire LDAP (bon je pourrais lire le code, ou tester, mais autant demander) : de quoi a vraiment besoin OBM ? Est-ce qu'on peut se contenter d'avoir la liste des utilisateurs, et éventuellement des groupes, dans le ldap ? Est-ce que c'est paramétrable au niveau des recherches ou est-ce qu'il faut trifouiller le code pour ça ? Est-ce que les recherches récursives sont possibles ?

Sachant que pour ce qui concerne la gestion des utilisateurs / boîtes, on a une appli maison qui fait ça très bien. De toutes manières, les problématiques spécifiques à l'utilisation des schémas LASER et sendmailv2 pour le MTA, ou le fait qu'on a plusieurs cyrus (murder), font que les solutions de gestion clef en main ont peu de chance de fonctionner.

Si quelqu'un a mis en oeuvre OBM en tant que "brique", à la façon de Horde, simplement pour la partie webmail / calendrier / groupware / synchro sans la gestion des utilisateurs et du routage, avec un ldap pré-existant, sans tout chambouler, je suis intéressé. Si ce n'est pas le cas, mais que ça a l'air techniquement possible, également ;-)

Tiens, en effet, ça serait une fonctionnalité intéressante, ça. Dénier des droits à une application...

Tu as pensé à la proposer sur le système de suivi d'android (http://code.google.com/p/android/issues/list) ?

La gestion des droits d'android n'est pas mal faite à ce niveau là.

Utiliser les données de localisation GSM via google provoque l'affichage d'un avertissement, et les applications qui ont accès à la localisation (gsm ou gps) le signalent à l'installation (au même titre que l'accès internet, l'envoi de SMS ou le déclenchement d'appels, etc). Les applications n'ont pas le droit d'activer la géolocalisation gsm ou gps sans action de l'utilisateur.

On sait donc à quoi s'en tenir.

Évidemment, si l'utilisateur ne tient pas compte des avertissements et ne cherche pas à comprendre pourquoi une application a besoin de telle ou telle fonctionnalité, ça ne sert à rien...

D'ailleurs, on voit que bon nombre d'utilisateurs sont prêts à sacrifier leurs données personnelles (ou professionnelles) en échange d'une fonctionnalité (il n'y a qu'à voir le nombre de gens utilisant gmail et autre agenda "dans le cloud"). Personnellement ça me désespère...

Un exemple : je me souviens d'une application, soit disant "antivirus" qui avait accès non seulement aux données stockées et à internet (ce qui fait souci si on n'a pas confiance), mais aussi aux données GPS, à l'agenda, pouvait envoyer des SMS et effectuer des appels. Inutile de dire qu'elle s'est rapidement faite signaler comme application suspecte. Ca n'a pas empêché un grand nombre de gens de la télécharger dans l'intervalle...

Il y plus de paquets, elle est donc plus généraliste ;-)

(mince on n'est plus vendredi... mais j'avais pas le temps hier !)

je suis du même avis.

SSH, c'est une connexion TCP. Netfilter ne se base pas sur un délai pour connaître l'état de connexion, mais sur les paquets échangés. Tant qu'il n'y a pas de FIN/FIN-ACK ou TCP-RST il n'y a aucune raison que les paquets soient droppés.

C'est facile à vérifier en rajoutant une règle LOG avant la règle DROP finale. Si des paquets sont droppés ils seront loggués. Si ils ne sont pas loggués, c'est que ce n'est pas netfilter le coupable...

j'ai souvent ce genre d'erreur avec gnutls-cli, alors que ça passe parfaitement avec openssl s_connect....

Cela dit je n'ai jamais bien compris pourquoi ;-)

J'ai eu un problème du même genre, firefox utilisait de plus en plus de ram et tirait 100% du temps cpu disponible au bout de quelques heures d'utilisation.

en partant sur un profil propre, le problème était réglé, jusqu'à ce que j'importe mes bookmarks : là ça revenait.

Au final j'ai fini par comprendre que c'était dû à des marque-pages dynamiques, qui n'étaient jamais purgés.

je ne peux que te conseiller d'utiliser la même méthodologie : partir sur un profil propre et importer petit à petit extensions, marque-pages, mots de passes, etc.

http://kb.mozillazine.org/Transferring_data_to_a_new_profile(...)

Le ping est filtré, ça n'est pas étonnant sur la passerelle 3G. Procède par ordre :

Essaye de pinguer un hôte plus loin, comme l'ip de google qu'on t'a donné précédemment.
Si ça marche, essaye de résoudre les noms (host www.google.fr par exemple). Si ça marche, essaye de surfer sur le web. Si ça ne marche pas, essaye de sniffer le traffic pour voir ce qui se passe (c'est peut-être une histoire de MTU, par exemple, paquets trop gros ne passant pas... C'est assez courant avec ppp, surtout quand il sert sur des protocles bizarres comme l'UMTS).

Pour vérifier si c'est une histoire de mtu, essaye d'envoyer des ping avec des payload élevés (-s 1500) et baisse jusqu'à ce que ça réponde. Utilise un moteur de recherche pour vérifier que les gens qui se connectent avec ppp au même provider que toi ont bien la même configuration à ce niveau. Je ne sais pas comment la connexion monte (script ou pppd), mais tu dois pouvoir spécifier le mtu d'une manière ou d'une autre :)

arf !
Quand j'ai lu ton post pour la première fois, je me suis dit "ah c'est un coup d'ICMP, puisque ça remplace arp en ipv6". Et en relisant j'ai vu que tu autorisais bien icmp, donc je me suis dit que ce n'était pas ça. Sauf qu'il faut autoriser icmpv6, en fait... C'est assez logique ;-)

après 3 seconde de réflexion, c'est logique que ça se fasse avec ip6table aussi, finalement : on doit pouvoir indiquer des adresses ipv4 en notation ipv6...

Il faudrait que tu mette un log pour voir ce qui est droppé (sur quelle interface, etc) pour en être sur, mais je dirais que ton tunnel ne peut pas s'établir, car tu n'autorise pas le trafic associé en INPUT.

Il faut que tu autorise le protocole SIT (-p 41) (ou peut-être GRE) en entrée. Par contre j'aurais dit que ça serait plutôt avec iptables, puisque c'est par définition de l'ipv4... Après je ne maîtrise pas bien le couple iptables / ip6table :)

et je m'aperçois que le fameux petit_bibi voit en substance le même problème que moi...
Si ça ne marche pas, on peut voir ta version du script et un exemple de log ?

Tu as essayé d'utiliser tcpdump pour comprendre ce qui se passe ?
(log + tcpdump -i any, généralement on a plus d'info).

La raison qui pourrait faire que ça ne marche pas ça serait une bizarrerie dûe à openvpn (je ne l'ai jamais vu sur du ppp, pour moi c'était tun ou tap...).

non !
DNAT= changement de destination = PREROUTING (il faut le faire avant de prendre la décision de routage).
SNAT= changement de source = POSTROUTING (ça se fait quand le paquet part, après le routage)

Ici, le problème est qu'il faut du DNAT et du SNAT.

En effet, ce qui se passe c'est :
A (172.16.0.0) -> (openvpn) interface tunnel (ppp) avec trafic à destination de la 10.8.0.0 -> DNAT (modification de la destination du paquet) vers 172.16.0.0

A ce stade, le paquet a une source en 172.16.0.0 et une destination de 172.16.0.0. Du coup, la destination n'a aucune raison de renvoyer le paquet au routeur qui se charge de la NAT. Il faut donc ajouter une règle de SNAT (du genre : iptables -t nat -A POSTROUTING- s <masque réseau A, disons 172.16.0.0/16> -d <masque réseau B, 172.16.0.0/16> -o <interface lan local> -j SNAT --to <ip locale>, ou plus simplement iptables -t nat -A POSTROUTING -s <masque réseau A> -d <masque réseau B> -o <interface locale B> -j MASQUERADE). C'est en plus de la règle de DNAT en prérouting sur le trafic à destination de 10.8.0.0 sur l'interface openvpn.

Il me semble que c'est ce que j'avais déjà répondu au premier post, mais bon, soit j'ai pas compris le problème, soit je m'explique pas clairement :-)

Après, quand on a le même réseau de chaque côté, c'est toujours galère dans les vpn...

Si on a besoin de faire des connexions point à point entre les machines du réseau A et du réseau B (et pas juste d'accéder à une machine du réseau B depuis le réseau A), le mieux est de faire un double NAT complet : http://www.netfilter.org/documentation/HOWTO//netfilter-doub(...)

Pour mieux comprendre l'enchainement des règles INPUT, FORWARD, OUTPUT, PREROUTING, et POSTROUTING : http://www.netfilter.org/documentation/HOWTO/netfilter-hacki(...) ou la "big picture" : http://linux-ip.net/nf/nfk-traversal.html

Déjà il faut s'assurer que le trafic que tu veux translater rentre bien par eth0 en PREROUTING (donc depuis le routeur proprement dit, ça ne marchera pas, il faut le faire depuis un hôte qui est connecté à eth0, directement ou pas). Il y a quelque part dans la doc netfilter un schéma du routage dans le noyau et des hooks netfilter associés, à accrocher jusqu'à ce qu'on le connaisse par coeur (je l'ai pas sous la main mais quelqu'un d'autre aura sûrement le lien).

D'autre part, si tu veux que ça marche, il faut que ton routeur soit la passerelle utilisée quand l'hôte de destination va répondre (si l'hôte de destination est dans le même réseau que la source, il va tenter de répondre directement, et ça va poser problème). Si ce n'est pas le cas, il faut modifier la route correspondante sur l'hôte destination, ou prévoir aussi du SNAT sur le routeur.

Enfin, je vois que tu veux que le trafic à destination de 10.1.0.1 accède à 10.1.0.2. On est plus dans le cas d'un REDIRECT que dans celui d'une translation, là... Ou alors il faut que tu fasse aussi un SNAT sur le routeur pour que les connexions aient l'air de venir de lui (ce qui n'est pas forcément ce que tu veux).

Si tu veux faire un proxy transparent, utilise REDIRECT.

Cela dit il est d'usage quand on a ce genre de souci de fournir un petit schéma simplifié afin qu'on ait une vue d'ensemble plutôt que d'imaginer ce qui pourrait éventuellement poser problème dans tel ou tel cas ;-)

ip route del default
ip route add default via 10.64.64.64 dev ppp0

(et tu peux faire ip route list plutôt que netstat -rn, au moins ce que tu verras sera plus proche de la syntaxe d'iproute, ça sera plus compréhensible)

oulaaaah, la fatigue... je voulais bien évidemment parler de /proc/mounts :-)

attention, /etc/mtab n'est pas forcément à jour. Il vaut mieux lancer "mount" sans argument, qui va regarder /proc/mtab.

Les outils P2V (physique to virtual) de vmware marchent plutôt bien (mais il faut un esxi, je le crains). Après il me semble bien qu'il y a possibilité de convertir des images vmware dans d'autres formats pour utiliser dans une autre solution de virtualisation, c'est probablement à creuser.

phpLDAPAdmin est l'équivalent de phpMyAdmin, à savoir, une interface web pour administrer le service LDAP, point. Si tu n'as aucune connaissance en LDAP, tu ne peux pas t'en servir.
Tu ne peux pas non plus permettre à des non-initiés d'exploiter des données.

Je nuancerai un poil, parce qu'avec sa gestion de gabarits, phpldapadmin permet de créer facilement des objets avec très peu de connaissances ldap (guère plus que quand on utilise le composant MMC microsoft "utilisateurs et ordinateurs active directory" pour gérer les utilisateurs et les groupes d'un annuaire AD, par exemple).
Ca reste moins convivial que GOsa, dans lequel on gère des utilisateurs et des groupes, et leurs propriétés, sans se préoccuper du fait qu'il y ait un ldap derrière. Disons que ça dépanne :-)

gni ? du nat en ipv6 ?
De mémoire, c'est prévu mais il n'y a encore aucune RFC finalisée, et surtout je ne connais pas d'implémentation, libre ou pas.

Bon après j'ai pas cherché, mais si il y a du NAT qui existe quelque part à l'heure actuelle, ou une RFC, voire un draft un peu avancé, je veux bien un lien ;-)

'fin bon, de toutes façons, le nat c'est Mal® (même si c'est parfois bien pratique...). Et en ipv6 pour un usage personnel je vois pas l'intérêt, si ce n'est une illusion de sécurité pour l'utilisateur endoctriné par les fabriquants de routeurs pour particuliers...

-42. tout est dit :-)