En regardant les exemples, j'ai l'impression que serval21 voudrait un lecteur audio/video dont les playlists se commandent/programment à distance via une interface web, je me trompe ?
Un peu le genre de truc qui doit commander les écrans LCD des lieux publics où sont diffusés de la pub et cie (voire, à Madrid, des telenovellas... flippant, quand on attend le métro, d'autant plus quand on voit des gens essayer de suivre les programmes, et encore plus quand se superpose une boîte de dialogue redmondienne avertissant que va savoir quoi a planté, sans que les gens ne décollent leur regard)...
Il me semble déjà avoir vu ce genre de choses pour de la zique, via des plugins pour des "groupwares", mais pas pour de la video. Sinon, conceptuellement, ça pourrait être une espèce de MPD pour de la video... peut-être avec VLC ? Il me semble qu'il est contrôlable via interface web.
Le principe de true crypt, c'est justement le déni plausible : a priori, on ne peut pas prouver qu'il y a un volume chiffré, tant qu'il n'est pas utilisé...
... bon maintenant, des gigots de données aléatoires, c'est un peu gros, pour la plupart des gens... surtout s'il y a les binaires de truecrypt installés sur la machine.
Après, m'en fous un peu, il n'est pas dans Debian (pour cause d'une licence très douteuse par le passé... paraît que ça a changé), donc, peu de chances que je l'utilise... et puis, m'est surtout avis que ça ne vaut pas un SFTP ou un VPN (via lesquels on peut accéder à des fichiers chiffrés aussi, si on veut). Trimballer des données chiffrées sur soi, je trouve ça un peu voyant...
S'ils sont assez cons pour envoyer des choses qu'ils considèrent privées en sachant que c'est exactement comme s'ils le marquaient au feutre noir sur une carte postale non enveloppée...
... c'est leur problème - mais au moins, ils sont au courant.
Personnellement, il y a des choses pour lesquelles je me fous que ce soit au dos d'une carte postale que le postier peut lire si ça le fait jouir... et des choses pour lesquelles je ne m'en fous pas. L'important est d'agir en connaissance de cause, non ?
Je n'ai pas réessayé le "multi-seat" depuis un moment, mais des souvenirs que j'en ai, on déclarait plusieurs sections "Screen", on les associait aux périphs d'entrée avec des sections "ServerLayout" distinctes, et on lançait plusieurs instances de X.org, chacune correspondant à un "ServerLayout" distinct sur un TTY différent...
... sauf que ça ne doit plus marcher, puisque RandR 1.2 rend le ServerLayout obsolète, ne permettant plus que d'avoir un seul "X.org screen"...
Logiquement, l'avenir du multi-seat devrait se trouver dans le "Multi-pointer X", pour gérer plusieurs utilisateurs dans la même session... après, j'imagine qu'il faudra aussi les "GPU objects", qui permettront d'apporter une couche d'abstraction sur l'utilisation des écrans.
J'attends cette feature (sans cesse repoussée) avec une impatience non dissimulée, pour que mon tri-écran remarche de nouveau sur une seule machine, avec deux GPU... mais a priori, ça devrait logiquement aussi permettre l'inverse, à savoir plusieurs sessions sur les sorties d'un même GPU ('fin j'imagine, c'est un peu le but de la chose : organiser son clickodrome avec ces couches d'abstraction, peu importe ce qu'il y a en dessous, au niveau matériel). Mais bon : ça devait arriver avec RandR 1.3, mais apparemment, c'est encore retardé. À ce niveau, X.org, c'est la grosse-grosse loose.
Sinon :
- X server 1.5 => X.org 7.4
- X server 1.4 => X.org 7.3
- X server 1.3 => X.org 7.2
- X server 1.2 => X.org 7.1
- X server 1.1 => X.org 7.0/6.9 (6.9=7.0, mais en non modulaire)
- X server 1.0 => X.org 6.8(/6.7 ? je ne sais plus trop... de toute façon, c'était une release de fork, donc, avec plein de XFree86 dedans)
... et avant, c'était le maelstrom originel, à la suite de l'implosion (bienfaitrice) de xfree86 (on y serait resté, les choses seraient encore pires), le précédent multivers.
RandR évolue beaucoup plus lentement, hélas... Il me semble que RandR 1.1 est apparu avec X.org 7.1, RandR 1.2 avec X.org 7.2, RandR 1.3 avec X.org 7.4... quant à RandR 1.4 (GPU objects ?), je ne l'attends même plus (de toute façon, ça fait presque deux ans que le multi-GPU est cassé, avec RandR 1.2, alors... 6 mois/1/2/3/... ans de plus, ou de moins...) : il sera là quand il sera là.
"Sandy, il faut toujours que tu dramatises : cet affreux Youri est mort. Youri n'est plus qu'un affreux souvenir, maintenant. Cet affreux CAU-chemar est terminé !"
???
... sinon, en googlant, iwantsandy a l'air d'un assistant en webmail, ou un truc du genre... mais... c'est quoi le rapport ?
> le niveau de sécurité de mon interface LAN est de 100 et celle de l'outside 0
Je ne vois pas trop ce que tu veux dire par là... question de politique interne, genre le siège B ne doit pas accéder au LAN du siège A ? Si c'est ça, un VPN pourrait introduire de la granularité dans ta DMZ, en permettant l'accès au CUPS uniquement à ceux qui s'authentifient sur le VPN, sans pour autant mettre le CUPS sur le LAN - en gros : le VPN est en DMZ, et donne accès à une imprimante qui est dans une DMZ "moins publique".
> Avec Openvpn comment ferais je la translation de port
Mettons que tu as un serveur VPN dans ton site A : les gens de ton site B utilisent un client VPN sur leur machine pour s'y connecter, et toutes leurs connexions sont encapsulées dans des paquets UDP qui sortent du client VPN. La gateway du site B envoie tout ça à la gateway du site A, qui NATe vers le port UDP 1194 du serveur VPN : les paquets en ressortent alors comme ils y sont entrés, ie à destination du port TCP 631 du CUPS du site A, avec son adresse interne sur le site A.
Le "client" VPN peut être global pour le site B, ie un seul VPN par lequel tout le monde passe, de sorte à avoir un tunnel ouvert en permanence, plutôt qu'à la demande. Pour interconnecter deux sites, c'est encore le plus simple, a priori. En gros, là, tu as un serveur VPN en DMZ de chaque côté, et il connecte les deux sites pour faire comme s'ils n'en faisaient qu'un, du point de vue des utilisateurs.
Un VPN ne fait qu'encapsuler des paquets dans d'autres, en les chiffrant, et après authentification, pour connecter deux sites distants, ou un utilisateur distant à un site. Une fois connecté, c'est exactement comme si on était en local, du point de vue utilisateur ; ce qui fait qu'il faut une certaine cohérence entre les deux sites, genre ne pas utiliser une adresse IP pour le CUPS du site A qui soit déjà utilisée sur le site B, par exemple.
Tu peux voir des VPN comme des distrans, dans Hypérion, ou des portes des étoiles dans Stargate :p
> est ce possible de faire communiquer openvpn dans le lan avec mon interface outside
Faudra quand même bien que le VPN écoute sur une interface publique, pour qu'il réponde aux demandes de connexion... donc, NATer vers lui, si tu n'as qu'une seule adresse publique.
Ah oui, sinon, pense bien à un truc : OK, là, avec ta DMZ, tu n'autorises que le site B à se connecter à ton CUPS... mais si tu n'utilises pas au moins SSL pour dialoguer avec ton CUPS, tu es conscient que tous les paquets de l'impression se baladent en clair sur le net, interceptables sans avoir à les déchiffrer par n'importe qui entre deux ? J'espère qu'il n'y a rien de confidentiel dans ce qui est imprimé, hein...
Ce n'est pas une question de droit, mais plus une question de compétences et de côté pratique.
Je pense que le mainteneur a déjà plus le nez dans le guidon que moi sur ces questions (je rencontre certes le problème... de là à le résoudre, ou à bien l'expliquer à ceux qui codent...)...
... en outre, comme tu le fais remarquer, ça crée une entrée pour le bug dans Debian, et ça me permettra de mieux identifier quand le problème sera résolu, vu que c'est dans cette distro (que j'utilise majoritairement), que je le rencontre principalement, suite à la décision de faire de rsyslog le logueur par défaut.
Je suis souvent passé par le rapport de bugs chez Debian, pour des problèmes qui concernaient le développement en amont, et en général, l'info suit bien ;)
Bah, tu peux voir un VPN comme une espèce de routeur ou de switch (selon que la plage d'adresses qu'il met à disposition pour les clients est sur le même sous-réseau que ce à quoi tu le branches), avec authentification : une fois connecté dessus, c'est comme si on était branché dans ton réseau...
L'avantage de passer par un VPN (s'il switche tes clients avec le serveur CUPS... à voir si c'est possible, voire souhaitable, dans ton cas), ça va aussi être que tu vas pouvoir bénéficier des broadcast CUPS, et donc, de l'autodétection de l'imprimante par les PC clients.
Quant au firewall, aucun souci pour OpenVPN : a priori, par défaut, le port 1194 en UDP lui suffit. Avec IPSec, ça peut être beaucoup plus chiant.
> À mon avis tu devrais signaler le problème sur le forum de rsyslog, ils sont en général très réactifs.
Clairement, il faudra que je parle du problème aux devs (que je passe par Debian en tant qu'intermédiaire ou pas... cela dit, vu que je ne suis qu'un pauvre mortel, ie j'ai quelques notions, mais je suis un amateur bien loin d'être capable de coder à ce niveau, passer par le "bugreport" de Debian pourrait ne pas être du luxe :p ... d'autant que rsyslog a été choisi entre autres parce qu'il semble y avoir une bonne entente entre devs Debian et Rainer)...
... m'enfin, pour Lenny, c'est de toute façon trop tard, je pense ('me suis déjà fait envoyer bouler quand j'ai rappelé que lcdproc n'avait pas été mis à jour depuis au moins Sarge, et que pour acheter des LCD supportés par la version qui sera dans Lenny, faut se lever tôt - et tout ça juste parce que le paquet pour s390 est trop vieux par rapport aux autres - le seul bug RC ayant été corrigé il y a plus d'un mois) - donc, en attendant, faudra bien que je me satisfasse de syslog-ng...
> bourre ta machine d'autant de ram que peut supporter ta carte mere
Voilà... l'est là, le problème :(
Niveau RAM, c'est blindé : je ne peux pas mettre plus de 3*1Gio sur mon A7N8X-E... quant à la KT4AV, elle a bien trois emplacements, mais ça bloque au BIOS si je mets une troisième barette de 1Gio (tu crois que je n'ai pas essayé, peut-être :p ?)...
Donc... Voilà... l'est là, le problème... Quand ça décédera, évidemment, je prendrais quelque chose qui ne sera pas autant intrinsèquement limité, que j'utilise un noyau 32bits bigmem, ou un 64 bits : en attendant, je fais avec ce que j'ai (quoique : plus tard ça arrive, mieux c'est - les mobos récentes avec 4 ports PCI, pour mes cartes DVB-T, ça ne court plus les rues).
Mes serveurs sont des vieilles machines de récup... ie, mes anciens desktops. Certes, on pourrait me reprocher que ça consomme sa race vis à vis de la puissance que ça a... d'un autre côté, les envoyer dans une décharge d'un quelconque pays du tiers-monde, pour que ça y pollue les nappes phréatiques et intoxique les ouvriers, est-ce fondamentalement mieux ?
En fait, dans un conteneur OpenVZ, le "used" d'un "free -m" va correspondre au "privvmpages", qui est la quantité de mémoire allouée (en pages de 4Kio), sans pour autant être nécessairement utilisée (la mémoire physique utilisée en pratique va plutôt être indiquée par oomguardpages [quantité de mémoire physique utilisée qui va faire que, au delà d'un certain seuil, les processus vont commencer à être tués] ou physmpages, qui ne vont en effet même pas varier d'1Mo en arrêtant rsyslog... pour une VM telle que je l'ai décrite, exim4-light, sshd, puppet et rsyslog, il y a ~19Mio de RAM physique occupée... mais significativement plus qui a été allouée). Les buffers et les caches ne sont pas virtualisés en tant que tels dans la VM : ils n'apparaissent "qu'en gros", sur l'hôte, lorsqu'on y fait un "free -m" (enfin, une partie apparaît aussi dans les beancounters, pour ce qui est des buffers de sockets et caches de système de fichiers, mais je ne pense pas que ça recouvre tout ceux qu'on trouve dans la mémoire de la machine).
Le souci étant qu'à allouer moins de ressources de l'hôte à la VM que ce qui est alloué par un "privvmpages", si une application se met à utiliser cette mémoire, elle peut planter lamentablement... À ce sujet, la doc d'OpenVZ conseille d'allouer du "privvmpages" en accord avec les ressources réelles de la machine.
Aussi, à partir du moment où une application commence à allouer beaucoup de mémoire, dans un conteneur, c'est gênant, quand bien même elle ne l'utilise pas en pratique... D'où mon désarroi face à rsyslog... Si je l'utilise, soit je réserve trop de RAM pour les VM, soit je joue avec le feu...
> Vu la quantité de conteneurs utilisés, l'un d'entre eux pourrait faire office de serveur syslog centralisé
Cette histoire m'y a fait penser, du coup ;)
À voir : je pense que ce serait une bonne idée que de s'y mettre, au moins pour les services que j'ouvre sur l'extérieur (mail et cie).
D'autant que j'ai deux serveurs à conteneurs, mais que tous les services externes sont sur la même machine : aussi, le fait que la centralisation des logs ne soit pas chiffrée ne serait pas franchement catastrophique...
En bidouillant un peu, tout à l'heure, je suis arrivé à gagner 8Mo (ce qui est plus que pas mal, ça fait ~1/3), en désactivant les logs du kernel (totalement inutile, dans un conteneur - or, il les prend aussi en charge, maintenant).
Par contre, je n'ai pas vraiment vu comment gagner plus, et sa surconsommation par rapport à syslog-ng reste toujours trop importante pour moi, pour la différence qu'il m'apporte, pour mon usage...
Pour ce qui est du support du reste, par défaut, il ne semble pas que TLS et cie soient activés dans la conf de base... quant à la gestion des bases de données, il faut faire venir des paquets disjoints pour mysql et pgsql...
Apparemment, syslog-ng fait aussi dans les bases de données, mais en supporte moins que rsyslog, qui supporte MSSQL et cie...
... en fait, selon ce que j'ai lu sur le blog de Rainer Gerhards, principal auteur de rsyslog, il y a deux syslog-ng : un libre, et un autre purement commercial, avec plus de fonctionnalités... ce qui serait l'une des raisons du fork de sysklogd par Rainer (ne pas toucher à syslog-ng, pour ne pas empiéter sur son modèle de rémunération, sans pour autant partir de zéro, dans sa démarche de développer de l'alternative aux logueurs puissants, ou syslog-ng est en situation de monoculture, d'après lui).
Bon, quant à moi, je l'ai dit : mes besoins sont très modestes, voire artisanaux - je ne centralise même pas encore mes logs (je m'amuse avec mes serveurs à titre purement personnel : disons que je fais du lego :p)... Du coup, le passage à rsyslog m'ennuie un peu, surtout du fait que je le trouve obèse, tout aussi bien qu'il puisse être (je n'ai clairement pas les compétences pour remettre ça en cause).
Après, avec la multiplication de mes conteneurs, et des services que je vais ouvrir à l'extérieur, j'y réfléchis... va falloir que je vois comment faire ça avec syslog-ng... Apparemment, à ce niveau, rsyslog est meilleur, puisqu'il semble que depuis sa version 3.19.0, il n'ait pas besoin de stunnel pour déporter les logs en TLS, contrairement à syslog-ng (sauf à prendre l'édition commerciale)... enfin, à voir.
Tiens, je n'avais pas encore vu, mais, OVH propose du SIP pour 2,39€ HT/mois : illimité vers fixes en France et dans 40 pays (plus cher pour appeler les mobiles - 0,12€/min, ce qui reste dans les eaux de la freephonie, si on compte les divers opérateurs, les heures pleines et creuses, ... il y a aussi du forfait)...
Néanmoins, de ce que j'en ai vu, pas encore d'AP avec ath5k, malheureusement (déjà que le mode client, c'est "limite" - ça marche bien, mais à condition de fixer manuellement le taux de transfert)...
... avec b43, j'y suis arrivé, via OpenWRT, tout-librement - mais avec certaines limites aussi : pas top stable, pas de WEP ni de WDS (m'en fous), pas de VAP (plusieurs AP virtuels sur une seule carte - je rêve du jour où ce sera possible librement, ce qui est encore balbutiant... je crois que c'est possible avec des chips Inel "récents"). Par contre, les cartes wifi sont soudées, sur ces bousins (et je crois que, maintenant, il faut prendre les WRT54GL, pour avoir quelque chose de compatible, et qu'ils sont plus limités en flash/RAM que les anciens WRT54GS).
> Par contre j'utilise SIP comme solution "PC-to-Phone", ou encore "telephone mobile wifi vers telephone" (*). Il y a freephonie pour les clients de free, 9talk pour les clients de neuf telecom et plein de fournisseurs SIP pas cher pour les autres. "Skype Out" est nettement plus cher.
Tiens question con... Orange n'était pas censé être passé au Sip aussi ? Je demande, hein, je n'en sais rien quant à l'utilisabilité, voire même la simple factualité ; il me semble juste en avoir entendu parler.
Mais si je pouvais passer par mon modem plutôt que de devoir brancher une livebox, et me mettre un petit asterisk dans un conteneur, relié à un téléphone IP, ça pourrait me tenter (au moins pour essayer, avec Ekiga, dans un premier temps)...
Sinon, en hexagone, puisque tu sembles renseigné, tu indiques quoi, comme solution tierce de PC-to-Phone ?
Ça dépend de ce que c'est comme Debian : Etch, Lenny, Sid ?
Avec Etch, oui, il faut spécifier le driver (X.org 7.1, si je m'en souviens). Avec Lenny (X.org 7.3), ça devrait même démarrer sans xorg.conf...
Sinon, c'est une série R400, selon ton autre sujet ( http://linuxfr.org/forums/15/26196.html )... a priori, ça marche sans problème avec des drivers libres (ça doit faire deux ans et demi que j'en ai : aucun souci majeur ; enfin, sous Etch, le driver est un peu vieux, et patine dans la choucroute, par exemple, sous l'interface OpenGL de MythTV - mais il marche)...
Pour vérifier que tu as bien l'accélération graphique, un petit "glxinfo|grep direct" ... Si c'est à "Yes", c'est bon, sinon, faudra peut-être un peu trifouiller... pour la résolution, faudra peut-être un poil trifouiller aussi, si celle par défaut ne te convient pas...
Donc Google largue le partenariat avec Yahoo, qui bien mari, essaye de se remettre avec Minimou, qui ne veut maintenant plus que "rester bons amis"...
On se croirait sur une production AB...
... d'un autre côté, ce n'est pas très rassurant pour la pérennité des boîtes mail à long terme non plus, vu l'état de Yahoo... M'enfin, on verra bien : j'imagine aussi qu'il y aura assez de latence pour se retourner si mal devait arriver.
Redmond lorgne sérieusement dessus, ce qui fait que ça risque à plus ou moins long terme de se transformer en hotmail...
Sinon, je ne jette pas la pierre non plus forcément : j'ai une adresse yahoo depuis un bon moment, et je m'en sers toujours.
Mais pour mes nouvelles adresses "jetables", je suis maintenant passé à gmail, qui est très bien aussi, _dans_ _ce_ _genre_ (même si, maintenant que j'ai un domaine, je pense à me louer un petit mutualisé pour lui mettre, par exemple, un Exim).
[^] # Re: ...
Posté par Aefron . En réponse au message solution d'affichage dynamique (PLV)/digital signage. Évalué à 3.
Un peu le genre de truc qui doit commander les écrans LCD des lieux publics où sont diffusés de la pub et cie (voire, à Madrid, des telenovellas... flippant, quand on attend le métro, d'autant plus quand on voit des gens essayer de suivre les programmes, et encore plus quand se superpose une boîte de dialogue redmondienne avertissant que va savoir quoi a planté, sans que les gens ne décollent leur regard)...
Il me semble déjà avoir vu ce genre de choses pour de la zique, via des plugins pour des "groupwares", mais pas pour de la video. Sinon, conceptuellement, ça pourrait être une espèce de MPD pour de la video... peut-être avec VLC ? Il me semble qu'il est contrôlable via interface web.
[^] # Re: Russe ...
Posté par Aefron . En réponse au journal Après DADVSI et HADOPI, voici ACTA. Évalué à 2.
... bon maintenant, des gigots de données aléatoires, c'est un peu gros, pour la plupart des gens... surtout s'il y a les binaires de truecrypt installés sur la machine.
Après, m'en fous un peu, il n'est pas dans Debian (pour cause d'une licence très douteuse par le passé... paraît que ça a changé), donc, peu de chances que je l'utilise... et puis, m'est surtout avis que ça ne vaut pas un SFTP ou un VPN (via lesquels on peut accéder à des fichiers chiffrés aussi, si on veut). Trimballer des données chiffrées sur soi, je trouve ça un peu voyant...
[^] # Re: Y en aura-t-il pour tous ?
Posté par Aefron . En réponse au journal Après DADVSI et HADOPI, voici ACTA. Évalué à 7.
Peeratageur ?
[^] # Re: Blackberries are for lolcats
Posté par Aefron . En réponse au journal Obama rendra son BlackBerry lors de sa prise de fonctions.. Évalué à 5.
[^] # Re: Blackberries are for lolcats
Posté par Aefron . En réponse au journal Obama rendra son BlackBerry lors de sa prise de fonctions.. Évalué à 6.
... c'est leur problème - mais au moins, ils sont au courant.
Personnellement, il y a des choses pour lesquelles je me fous que ce soit au dos d'une carte postale que le postier peut lire si ça le fait jouir... et des choses pour lesquelles je ne m'en fous pas. L'important est d'agir en connaissance de cause, non ?
[^] # Re: et le multiseat :'(
Posté par Aefron . En réponse à la dépêche Phoronix souhaite savoir comment vous utilisez Xorg. Évalué à 4.
... sauf que ça ne doit plus marcher, puisque RandR 1.2 rend le ServerLayout obsolète, ne permettant plus que d'avoir un seul "X.org screen"...
Logiquement, l'avenir du multi-seat devrait se trouver dans le "Multi-pointer X", pour gérer plusieurs utilisateurs dans la même session... après, j'imagine qu'il faudra aussi les "GPU objects", qui permettront d'apporter une couche d'abstraction sur l'utilisation des écrans.
J'attends cette feature (sans cesse repoussée) avec une impatience non dissimulée, pour que mon tri-écran remarche de nouveau sur une seule machine, avec deux GPU... mais a priori, ça devrait logiquement aussi permettre l'inverse, à savoir plusieurs sessions sur les sorties d'un même GPU ('fin j'imagine, c'est un peu le but de la chose : organiser son clickodrome avec ces couches d'abstraction, peu importe ce qu'il y a en dessous, au niveau matériel). Mais bon : ça devait arriver avec RandR 1.3, mais apparemment, c'est encore retardé. À ce niveau, X.org, c'est la grosse-grosse loose.
Sinon :
- X server 1.5 => X.org 7.4
- X server 1.4 => X.org 7.3
- X server 1.3 => X.org 7.2
- X server 1.2 => X.org 7.1
- X server 1.1 => X.org 7.0/6.9 (6.9=7.0, mais en non modulaire)
- X server 1.0 => X.org 6.8(/6.7 ? je ne sais plus trop... de toute façon, c'était une release de fork, donc, avec plein de XFree86 dedans)
... et avant, c'était le maelstrom originel, à la suite de l'implosion (bienfaitrice) de xfree86 (on y serait resté, les choses seraient encore pires), le précédent multivers.
RandR évolue beaucoup plus lentement, hélas... Il me semble que RandR 1.1 est apparu avec X.org 7.1, RandR 1.2 avec X.org 7.2, RandR 1.3 avec X.org 7.4... quant à RandR 1.4 (GPU objects ?), je ne l'attends même plus (de toute façon, ça fait presque deux ans que le multi-GPU est cassé, avec RandR 1.2, alors... 6 mois/1/2/3/... ans de plus, ou de moins...) : il sera là quand il sera là.
[^] # Re: tu utilises sandy ?
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 2.
... non, en fait, plutôt un fan de Mr Hankey, le Petit Caca Noël de South Park : howdy-hooooo ! :D
[^] # Re: tu utilises sandy ?
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 2.
"Sandy, il faut toujours que tu dramatises : cet affreux Youri est mort. Youri n'est plus qu'un affreux souvenir, maintenant. Cet affreux CAU-chemar est terminé !"
???
... sinon, en googlant, iwantsandy a l'air d'un assistant en webmail, ou un truc du genre... mais... c'est quoi le rapport ?
[^] # Re: Très bonne idée
Posté par Aefron . En réponse au message impression à distance. Évalué à 3.
Je ne vois pas trop ce que tu veux dire par là... question de politique interne, genre le siège B ne doit pas accéder au LAN du siège A ? Si c'est ça, un VPN pourrait introduire de la granularité dans ta DMZ, en permettant l'accès au CUPS uniquement à ceux qui s'authentifient sur le VPN, sans pour autant mettre le CUPS sur le LAN - en gros : le VPN est en DMZ, et donne accès à une imprimante qui est dans une DMZ "moins publique".
> Avec Openvpn comment ferais je la translation de port
Mettons que tu as un serveur VPN dans ton site A : les gens de ton site B utilisent un client VPN sur leur machine pour s'y connecter, et toutes leurs connexions sont encapsulées dans des paquets UDP qui sortent du client VPN. La gateway du site B envoie tout ça à la gateway du site A, qui NATe vers le port UDP 1194 du serveur VPN : les paquets en ressortent alors comme ils y sont entrés, ie à destination du port TCP 631 du CUPS du site A, avec son adresse interne sur le site A.
Le "client" VPN peut être global pour le site B, ie un seul VPN par lequel tout le monde passe, de sorte à avoir un tunnel ouvert en permanence, plutôt qu'à la demande. Pour interconnecter deux sites, c'est encore le plus simple, a priori. En gros, là, tu as un serveur VPN en DMZ de chaque côté, et il connecte les deux sites pour faire comme s'ils n'en faisaient qu'un, du point de vue des utilisateurs.
Un VPN ne fait qu'encapsuler des paquets dans d'autres, en les chiffrant, et après authentification, pour connecter deux sites distants, ou un utilisateur distant à un site. Une fois connecté, c'est exactement comme si on était en local, du point de vue utilisateur ; ce qui fait qu'il faut une certaine cohérence entre les deux sites, genre ne pas utiliser une adresse IP pour le CUPS du site A qui soit déjà utilisée sur le site B, par exemple.
Tu peux voir des VPN comme des distrans, dans Hypérion, ou des portes des étoiles dans Stargate :p
> est ce possible de faire communiquer openvpn dans le lan avec mon interface outside
Faudra quand même bien que le VPN écoute sur une interface publique, pour qu'il réponde aux demandes de connexion... donc, NATer vers lui, si tu n'as qu'une seule adresse publique.
Ah oui, sinon, pense bien à un truc : OK, là, avec ta DMZ, tu n'autorises que le site B à se connecter à ton CUPS... mais si tu n'utilises pas au moins SSL pour dialoguer avec ton CUPS, tu es conscient que tous les paquets de l'impression se baladent en clair sur le net, interceptables sans avoir à les déchiffrer par n'importe qui entre deux ? J'espère qu'il n'y a rien de confidentiel dans ce qui est imprimé, hein...
[^] # Re: Conso de rsyslog
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 2.
Ce n'est pas une question de droit, mais plus une question de compétences et de côté pratique.
Je pense que le mainteneur a déjà plus le nez dans le guidon que moi sur ces questions (je rencontre certes le problème... de là à le résoudre, ou à bien l'expliquer à ceux qui codent...)...
... en outre, comme tu le fais remarquer, ça crée une entrée pour le bug dans Debian, et ça me permettra de mieux identifier quand le problème sera résolu, vu que c'est dans cette distro (que j'utilise majoritairement), que je le rencontre principalement, suite à la décision de faire de rsyslog le logueur par défaut.
Je suis souvent passé par le rapport de bugs chez Debian, pour des problèmes qui concernaient le développement en amont, et en général, l'info suit bien ;)
[^] # Re: Très bonne idée
Posté par Aefron . En réponse au message impression à distance. Évalué à 2.
L'avantage de passer par un VPN (s'il switche tes clients avec le serveur CUPS... à voir si c'est possible, voire souhaitable, dans ton cas), ça va aussi être que tu vas pouvoir bénéficier des broadcast CUPS, et donc, de l'autodétection de l'imprimante par les PC clients.
Quant au firewall, aucun souci pour OpenVPN : a priori, par défaut, le port 1194 en UDP lui suffit. Avec IPSec, ça peut être beaucoup plus chiant.
[^] # Re: Conso de rsyslog
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 1.
Clairement, il faudra que je parle du problème aux devs (que je passe par Debian en tant qu'intermédiaire ou pas... cela dit, vu que je ne suis qu'un pauvre mortel, ie j'ai quelques notions, mais je suis un amateur bien loin d'être capable de coder à ce niveau, passer par le "bugreport" de Debian pourrait ne pas être du luxe :p ... d'autant que rsyslog a été choisi entre autres parce qu'il semble y avoir une bonne entente entre devs Debian et Rainer)...
... m'enfin, pour Lenny, c'est de toute façon trop tard, je pense ('me suis déjà fait envoyer bouler quand j'ai rappelé que lcdproc n'avait pas été mis à jour depuis au moins Sarge, et que pour acheter des LCD supportés par la version qui sera dans Lenny, faut se lever tôt - et tout ça juste parce que le paquet pour s390 est trop vieux par rapport aux autres - le seul bug RC ayant été corrigé il y a plus d'un mois) - donc, en attendant, faudra bien que je me satisfasse de syslog-ng...
[^] # Re: quantite de ram ?? faux probleme
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 3.
Voilà... l'est là, le problème :(
Niveau RAM, c'est blindé : je ne peux pas mettre plus de 3*1Gio sur mon A7N8X-E... quant à la KT4AV, elle a bien trois emplacements, mais ça bloque au BIOS si je mets une troisième barette de 1Gio (tu crois que je n'ai pas essayé, peut-être :p ?)...
Donc... Voilà... l'est là, le problème... Quand ça décédera, évidemment, je prendrais quelque chose qui ne sera pas autant intrinsèquement limité, que j'utilise un noyau 32bits bigmem, ou un 64 bits : en attendant, je fais avec ce que j'ai (quoique : plus tard ça arrive, mieux c'est - les mobos récentes avec 4 ports PCI, pour mes cartes DVB-T, ça ne court plus les rues).
Mes serveurs sont des vieilles machines de récup... ie, mes anciens desktops. Certes, on pourrait me reprocher que ça consomme sa race vis à vis de la puissance que ça a... d'un autre côté, les envoyer dans une décharge d'un quelconque pays du tiers-monde, pour que ça y pollue les nappes phréatiques et intoxique les ouvriers, est-ce fondamentalement mieux ?
[^] # Re: Conso de rsyslog
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 3.
Niveau mémoire résidente (RSZ, à un "ps aux"), rsyslogd est bien tout petit (~1Mio)...
Pour les buffers et les caches, ils ne sont pas virtualisés à la vue de la VM, et restent à "0" tout le temps, à un "free -m".
Sur une machine "normale", ça me fait comme toi : ~1Mio de différence... mais dans le conteneur, j'obtiens :
$ echo && free -m && echo ; sudo invoke-rc.d rsyslog stop && echo ; free -m && echo ; sudo invoke-rc.d rsyslog start && echo ; free -m
total used free shared buffers cached
Mem: 256 45 210 0 0 0
-/+ buffers/cache: 45 210
Swap: 0 0 0
Stopping enhanced syslogd: rsyslogd.
total used free shared buffers cached
Mem: 256 28 227 0 0 0
-/+ buffers/cache: 28 227
Swap: 0 0 0
Starting enhanced syslogd: rsyslogd.
total used free shared buffers cached
Mem: 256 45 210 0 0 0
-/+ buffers/cache: 45 210
Swap: 0 0 0
En fait, dans un conteneur OpenVZ, le "used" d'un "free -m" va correspondre au "privvmpages", qui est la quantité de mémoire allouée (en pages de 4Kio), sans pour autant être nécessairement utilisée (la mémoire physique utilisée en pratique va plutôt être indiquée par oomguardpages [quantité de mémoire physique utilisée qui va faire que, au delà d'un certain seuil, les processus vont commencer à être tués] ou physmpages, qui ne vont en effet même pas varier d'1Mo en arrêtant rsyslog... pour une VM telle que je l'ai décrite, exim4-light, sshd, puppet et rsyslog, il y a ~19Mio de RAM physique occupée... mais significativement plus qui a été allouée). Les buffers et les caches ne sont pas virtualisés en tant que tels dans la VM : ils n'apparaissent "qu'en gros", sur l'hôte, lorsqu'on y fait un "free -m" (enfin, une partie apparaît aussi dans les beancounters, pour ce qui est des buffers de sockets et caches de système de fichiers, mais je ne pense pas que ça recouvre tout ceux qu'on trouve dans la mémoire de la machine).
Le souci étant qu'à allouer moins de ressources de l'hôte à la VM que ce qui est alloué par un "privvmpages", si une application se met à utiliser cette mémoire, elle peut planter lamentablement... À ce sujet, la doc d'OpenVZ conseille d'allouer du "privvmpages" en accord avec les ressources réelles de la machine.
Aussi, à partir du moment où une application commence à allouer beaucoup de mémoire, dans un conteneur, c'est gênant, quand bien même elle ne l'utilise pas en pratique... D'où mon désarroi face à rsyslog... Si je l'utilise, soit je réserve trop de RAM pour les VM, soit je joue avec le feu...
[^] # Re: Serveur de logs centralisé
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 2.
Cette histoire m'y a fait penser, du coup ;)
À voir : je pense que ce serait une bonne idée que de s'y mettre, au moins pour les services que j'ouvre sur l'extérieur (mail et cie).
D'autant que j'ai deux serveurs à conteneurs, mais que tous les services externes sont sur la même machine : aussi, le fait que la centralisation des logs ne soit pas chiffrée ne serait pas franchement catastrophique...
[^] # Re: Et rendre rsyslog plus leger ?
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 2.
Par contre, je n'ai pas vraiment vu comment gagner plus, et sa surconsommation par rapport à syslog-ng reste toujours trop importante pour moi, pour la différence qu'il m'apporte, pour mon usage...
Pour ce qui est du support du reste, par défaut, il ne semble pas que TLS et cie soient activés dans la conf de base... quant à la gestion des bases de données, il faut faire venir des paquets disjoints pour mysql et pgsql...
[^] # Re: syslog-ng
Posté par Aefron . En réponse au journal Debian Lenny, rsyslog et les conteneurs : de mes maniaquerie, radinerie et indigence. Évalué à 3.
... en fait, selon ce que j'ai lu sur le blog de Rainer Gerhards, principal auteur de rsyslog, il y a deux syslog-ng : un libre, et un autre purement commercial, avec plus de fonctionnalités... ce qui serait l'une des raisons du fork de sysklogd par Rainer (ne pas toucher à syslog-ng, pour ne pas empiéter sur son modèle de rémunération, sans pour autant partir de zéro, dans sa démarche de développer de l'alternative aux logueurs puissants, ou syslog-ng est en situation de monoculture, d'après lui).
Bon, quant à moi, je l'ai dit : mes besoins sont très modestes, voire artisanaux - je ne centralise même pas encore mes logs (je m'amuse avec mes serveurs à titre purement personnel : disons que je fais du lego :p)... Du coup, le passage à rsyslog m'ennuie un peu, surtout du fait que je le trouve obèse, tout aussi bien qu'il puisse être (je n'ai clairement pas les compétences pour remettre ça en cause).
Après, avec la multiplication de mes conteneurs, et des services que je vais ouvrir à l'extérieur, j'y réfléchis... va falloir que je vois comment faire ça avec syslog-ng... Apparemment, à ce niveau, rsyslog est meilleur, puisqu'il semble que depuis sa version 3.19.0, il n'ait pas besoin de stunnel pour déporter les logs en TLS, contrairement à syslog-ng (sauf à prendre l'édition commerciale)... enfin, à voir.
[^] # Re: Très bonne idée
Posté par Aefron . En réponse au message impression à distance. Évalué à 2.
... mais en effet, j'aurais plutôt tendance à voir ça comme un service interne, qui aurait plus sa place derrière un VPN.
[^] # Re: Combinaison Skype/SIP
Posté par Aefron . En réponse au message VoIP : Arguments pro & contra les alternatives à Skype. Évalué à 2.
[^] # Re: Combinaison Skype/SIP
Posté par Aefron . En réponse au message VoIP : Arguments pro & contra les alternatives à Skype. Évalué à 2.
... et apparemment, il y a le caller-id...
... hum, décidément, à voir le SIP, à voir...
[^] # Re: Hmmm ....
Posté par Aefron . En réponse au message Recherche carte wifi broadcom b43. Évalué à 2.
... avec b43, j'y suis arrivé, via OpenWRT, tout-librement - mais avec certaines limites aussi : pas top stable, pas de WEP ni de WDS (m'en fous), pas de VAP (plusieurs AP virtuels sur une seule carte - je rêve du jour où ce sera possible librement, ce qui est encore balbutiant... je crois que c'est possible avec des chips Inel "récents"). Par contre, les cartes wifi sont soudées, sur ces bousins (et je crois que, maintenant, il faut prendre les WRT54GL, pour avoir quelque chose de compatible, et qu'ils sont plus limités en flash/RAM que les anciens WRT54GS).
[^] # Re: Combinaison Skype/SIP
Posté par Aefron . En réponse au message VoIP : Arguments pro & contra les alternatives à Skype. Évalué à 2.
Tiens question con... Orange n'était pas censé être passé au Sip aussi ? Je demande, hein, je n'en sais rien quant à l'utilisabilité, voire même la simple factualité ; il me semble juste en avoir entendu parler.
Mais si je pouvais passer par mon modem plutôt que de devoir brancher une livebox, et me mettre un petit asterisk dans un conteneur, relié à un téléphone IP, ça pourrait me tenter (au moins pour essayer, avec Ekiga, dans un premier temps)...
Sinon, en hexagone, puisque tu sembles renseigné, tu indiques quoi, comme solution tierce de PC-to-Phone ?
[^] # Re: dpkg-reconfigure xserver-xorg
Posté par Aefron . En réponse au message carte graphique non reconnu sur Debian. Évalué à 2.
Avec Etch, oui, il faut spécifier le driver (X.org 7.1, si je m'en souviens). Avec Lenny (X.org 7.3), ça devrait même démarrer sans xorg.conf...
Sinon, c'est une série R400, selon ton autre sujet ( http://linuxfr.org/forums/15/26196.html )... a priori, ça marche sans problème avec des drivers libres (ça doit faire deux ans et demi que j'en ai : aucun souci majeur ; enfin, sous Etch, le driver est un peu vieux, et patine dans la choucroute, par exemple, sous l'interface OpenGL de MythTV - mais il marche)...
Pour vérifier que tu as bien l'accélération graphique, un petit "glxinfo|grep direct" ... Si c'est à "Yes", c'est bon, sinon, faudra peut-être un peu trifouiller... pour la résolution, faudra peut-être un poil trifouiller aussi, si celle par défaut ne te convient pas...
[^] # Re: Début de solution
Posté par Aefron . En réponse au journal hotmail sapusaidepireenpire. Évalué à 3.
Donc Google largue le partenariat avec Yahoo, qui bien mari, essaye de se remettre avec Minimou, qui ne veut maintenant plus que "rester bons amis"...
On se croirait sur une production AB...
... d'un autre côté, ce n'est pas très rassurant pour la pérennité des boîtes mail à long terme non plus, vu l'état de Yahoo... M'enfin, on verra bien : j'imagine aussi qu'il y aura assez de latence pour se retourner si mal devait arriver.
[^] # Re: Début de solution
Posté par Aefron . En réponse au journal hotmail sapusaidepireenpire. Évalué à 2.
Sinon, je ne jette pas la pierre non plus forcément : j'ai une adresse yahoo depuis un bon moment, et je m'en sers toujours.
Mais pour mes nouvelles adresses "jetables", je suis maintenant passé à gmail, qui est très bien aussi, _dans_ _ce_ _genre_ (même si, maintenant que j'ai un domaine, je pense à me louer un petit mutualisé pour lui mettre, par exemple, un Exim).