Posté par lay .
En réponse au message OpenVPN lent CentOS 6.3.
Évalué à 6.
Dernière modification le 12 octobre 2012 à 17:18.
Bonjour,
Pour avoir un début de piste, essayes de regarder avec tcpdump sur le tunnel pour voir si la connexion TCP à travers le VPN a bonne allure et n'a pas de fragmentation.
Si il y a de la fragmentation, regardes du coté des réglages mtu, fragment ou mssfix dans le manuel d'openvpn, un mauvais réglage peut entrainer des problèmes du genre :)
J'ai l'offre "fibre" de Numéricable (bien sur c'est un simple coaxial) sur Rennes depuis plus de deux ans et j'en suis assez content.
Au niveau du débit maximum ça tourne vers 8.5Mo/sec et les coupures sont rares. Deux fois FT a coupé le câble pensant qu'il ne servait a rien…
Par contre j'ai aussi un abonnement free en adsl en dégroupage total, très lojn du DSLAM avec un débit très faible, et curieusement le ping sur la ligne ADSL est meilleur que celui de Numéricable.
Le service est OK dans l'ensemble, par contre gros point noir au tout début!
Lors de mon abonnement, ils m'ont installé une box 10Mb/s au lieu de celle à 100Mb/s, et franchement ils n'ont pas été très clair sur le sujet, entre l'installateur mal à l'aise une fois que je lui ai dit que j'étais dans le métier, le service client m'assurant que j'avais bien une box 100Mb/s, le vendeur en boutique qui était loin d'être surpris me donnant des excuses bidon. Si ça n'avait pas été la seule solution pour avoir du gros débit chez moi j'aurais été voir ailleurs dès que possible.
Passer cette épreuve, le service est pour ma part bien rendu.
La commande ifconfig n'utilise pas le fichier de configuration, ifconfig down eth0 va donc simplement supprimer eth0 sans faire quoique ce soit d'autre.
Ça ne m'étonne donc pas que ifdown ou ifup ne fonctionnent pas correctement ensuite car l'état de l'interface a été modifié entre temps.
N'utilises donc pas ifconfig mais plutôt les outils fournis par debian.
Pour ce qui est de la conf DNS, une solution serait de renseigner directement le fichier /etc/resolv.conf et ne pas mettre de dns-nameservers dans le fichier de config.
Mais tout ça est à prendre avec des pincettes, je ne suis pas utilisateur acharné de debian :)
Le système hôte est une gentoo à laquelle sont assignées 3 IP, une spécifique à l'admin, une pour l'utilisation perso, et une pour les invités.
L'hôte fait tourner des VM KVM sous debian, toutes reliées à un bridge réseau virtuel afin de créer un LAN interne, une des VM est spécialisée dans les services réseau du LAN interne tel que DHCP ou DNS en splited horizon. Ensuite en gros il y a une VM par service, tel quel mysql, une qui fait office de NAS qui exporte du nfs, samba, ftp avec pas mal d'espace, une pour tout ce qui est mail. Dans une VM il y a un nginx qui sert de frontal pour tout les sites de la machine, que ce soit pour la VM qui contient un apache pour plusieurs sites mutualisés ou alors pour des VMs invités. Il y en a une qui sert de serveur VPN pour que je puisse me connecter a partir de chez moi sur le LAN virtuel, acceder a samba ou nfs depuis mon poste, et une autre qui sert de passerelle réseau en partance vers un vpn en hollande (en fait chaque VM peut choisir si elle a accès a un internet par OVH ou part le VPN en choisissant la bonne passerelle dans sa conf réseau).
Pour tout ce qui est firewall et NAT sur l'hôte afin de faire fonctionner tout ça c'est du shorewall.
Bref ça fait tout un tas de services, c'est surtout pour faire joujou, il n'y a rien de critique qui tourne et en cas de problème seule ma fierté prendrait un coup auprès des invités :D
Mais en écrivant cela je me rend compte qu'il serait temps que je jettes un œil coté monitoring rien que pour avoir une vision plus claire.
C'est un système qui commence à dater, je devrais le dépoussiérer un peu.
C'est un hôte gentoo qui fait tourner des vservers eux aussi sous gentoo (le proco n'a pas d'instructions VT…).
C'était vraiment très fun a l'installation mais un peu lourd à la longue :)
C'est la seule machine chez moi qui tourne en permanence et c'est un raid 1.
J'ai aussi un petit dédié chez OVH, et justement cette machine n'a pas de raid (question de budget), d’où ma demande d'un petit outil faisant le travail pour les disques, raids ou autres pièces.
A voir où il serait le plus judicieux d'installer le système de monitoring.
J'ouvre une nouvelle file afin de vous répondre a tous.
D'abord merci pour vos réponses, cela me conforte dans le fait qu'il n'existe pas un petit daemon spécialisé capable de faire ça simplement sans déployer une solution de monitoring plus complexe, c'est un peu dommage car c'est utiliser pas mal de temps en déploiement pour un événement qui n'arrivera peut être jamais.
Il reste smartd qui fait le travail uniquement pour les disques dur.
Mais cela fait un petit moment que l'installation d'un nagios ou d'un shinken me démange, ce sera l’occasion de sauter le pas.
Premièrement tu configure ta box pour faire du DNAT vers ta debian sur le port 5000. Apparemment tu l'as déjà fait.
Le DNAT change seulement la destination du paquet, donc depuis l’extérieur tu aura accès a ta debian sur le port 5000, la debian verra arriver une connexion depuis l'IP de ton tel.
Ensuite sur la debian, il faut faire du SNAT sur le port 5000 en écoute pour rediriger le trafic vers ta caméra. Le SNAT change la source des paquets, donc ta camera verra une connexion depuis la debian alors que le paquet provient bien de ton tel. De cette manière même les paquets en retour passe par la débian, ce qui permet de maintenir l'état de la connexion et de te débarrasser de problèmes réseau.
Ensuite il faut que tu puisse laisser le trafic sur le port 5000 à la demande sur la debian. Pour ça il y à le port knocking qui répond à ton besoin.
Dans le principe une application sur ton tel essaye de se connecté a des ports bien précis chez toi, le daemon détecte la combinaison, et ajoute l'IP ayant fait la combinaison en white list un certain moment.
Pour rectifier je dirais que dans la culture occidentale actuelle le Père Noël a une crédibilité moindre et est surtout associé à la naïveté des enfants.
Et moi je rajouterais que dans ma propre culture actuelle la religion a une crédibilité moindre et est surtout associé à la naïveté de certains adultes.
Pour que ce soit plus pratique tu peux déjà créer un dossier avec les droits de ton applicatif contenant un fichier de conf par virtualhost, chaque fichier de conf serait généré par ton applicatif.
Tu n'as plus qu'a inclure ce dossier depuis ton httpd.conf avec par exemple "Include virtualhosts/*.conf".
Pour relancer apache tu peux faire un script avec le bit Suid positionné, en faisant bien gaffe aux droits d’écriture sur le script. Cela permet de lancer le script en root si le script appartient à root.
Sinon pour faire un truc tip-top de la mort qui tue, je partirai personnellement vers des webservices qui font les actions de bases sur le système (par exemple un petit webserver en python), et une interface en php qui fait uniquement appel aux webservices pour faire le travail. Ainsi tu pourrais déployer les webservices sur plusieurs dédiés et avec une interface sur un seul dédié pour les centraliser.
Pour le risque de plantage au redémarrage d'apache qui entrainerai une perte de l'interface, une solution serait de mettre un nginx en frontal, qui sur un virtualhost afficherait le panel d'admin, et qui ferait un reverse proxy vers ton vrai apache pour tout les autres virtualhosts.
Tu parles de sources numériques et analogiques, et justement en discutant avec un revendeur spécialiste de la Hi-Fi, il m'a proposé de partir sur une source numérique pour la pièce principale avec un DAC et du bon matériel de diffusion, et des sorties analogiques pour le reste des zones qui seront bien moins armées.
Mais il faut avant que je test la faisabilité, car ça implique du matériel hétérogène qui peut impacter une de mes contraintes qui est la synchronisation des différentes zones (autant mettre la barre haute dès le début :). Si ce n'est pas le cas, il faudra faire un choix entre la synchro et la qualité. Je m'interroge d’ailleurs sur la latence engendrée par des éléments sans fils.
Du coté software, nous avons des différences au niveau des sources, et ça entraine une différence d'approche dans la gestion du son. Comme toi je compte mettre différent type de sources :
- Un MPD, pour la radio et une bibliothèque locale. D'ailleurs tu m'apprends qu'il peut gérer plusieurs output, ça sera un gros avantage.
- Un client Spotify grâce à leur libsoptify.
- Un serveur airplay pour les iBidules.
- Un serveur Bluetooth pour les autres
- Etc
Mais avec autant de sources différentes je pense qu'il sera plus facile et plus maintenable d'unifier le routage du son dans une couche qui sera entre les logiciels de lecture et la carte son.
Voici donc un premier retour de mes tests, cela te donnera peut être des idées :)
Pour le moment je suis partit sur Jack, qui justement est spécialisé dans la connexion entre input et output de flux audio, et qui pour un début fait vraiment bien son travail. Après avoir fouiller les docs et les howto voici le principe:
J'ai choisis d'unifier les output des applis en utilisant le module snd_aloop d'alsa. Celui ci permet de créer des cartes son virtuelles, avec chacune 8 sorties. Ce module redirige simplement son input dans un output associé.
Dans asound.conf il faut créer pour chaque logiciel un PCM qui lui sera destiné et qui sera lié à une entrée de la carte virtuelle.
Chaque logiciel est donc configuré avec comme output le PCM qui lui est attribué. A partir de ce moment la, on a donc un moyen de lancer tout les logiciel pour lire de l'audio et de le sortir en utilisant uniquement alsa. On a un style d'output unifié :) Bien sur pour le moment les flux sont joués dans le vide.
Et la intervient Jack, qui va nous permettre de router à la volée les PCM virtuels vers les bonnes sorties de la carte son. Il permet de router le son d'un point A à un point B, et ceci dans n'importe quel sens et dans n'importe qu'elle combinaison, en faisant le mixing au passage si besoin. Pour que jack reconnaisse les canaux de la carte virtuelle il faut utiliser les outils alsa_input et alsa_output. L'interface qjackctl permet d'avoir une bonne vision du résultat de la chose.
Une fois que jack a en entrée les flux sortant des applis, il suffit de les mapper vers les bonnes sorties de la carte son, qu'il reconnait directement dans mon cas. Pour le moment je le fait manuellement, mais il il y à plusieur moyen de le piloter logiciellement :)
Voici mon premier POC et ça me donne pour le moment satisfaction.
Je suis ouvert à toutes idées, et niveau matos je n'ai pas encore bien regardé :-\
C'est un système qui pourrait fonctionner, au même titre que la solution DLNA proposée ci-dessus.
je l'ai d’ailleurs mis en place il a un bon moment pour faire de la diffusion sur un site web a partir d'une bibliothèque locale et ça fait bien le travail :)
Mais j'ai une contrainte forte aujourd'hui qui est la qualité du son arrivant aux amplis, que je veux le plus proche possible d'un signal Hi-Fi, proche du signal d'origine, afin de pouvoir profiter pleinement de bonnes enceintes au moins pour la pièce principale :)
Et c'est la que ça pêche, je ne pense pas qu'un petit système du genre raspberry pi soit capable de sortir un très bon signal, ou alors monter de petits systèmes avec une bonne carte son à chaque fois mais le budget en prendra un coup. J'ai regardé du coté des récepteurs dlna de grande marque de l'audio, et c'est hors de prix et c'est limité coté fonctionnalités.
De plus, plus je rajoute d'intermédiaires entre le la lecture du fichier et la sortie vers l'ampli, moins il y a de chance que le son soit proche de l'origine, et donc finalement plus de chance de me planter :)
C'est pour cela que je me suis dirigé vers un système unique, avec une seule carte son, moins de technologie différentes, qui est finalement un système plus simple et donc moins risqué. Bon il restera à tirer les cables :)
Mais ce qui me fait peur dans ce genre d'installation c'est :
- le risque de décalage du son entre plusieurs zones avec une seule source (buffers, latence réseau, etc), surtout que je peux pas tester sans avoir investit dans un minimum de matos.
- la qualité du son HI-FI pouvant être retranscrit comparé au système que j'ai proposé.
Mais c'est vrai que c'est une solution qui serait plus pratique.
Pour ce qui est de la carte son, justement la M-Audio delta 1010 fait partie de ma short list, content d'apprendre qu'elle soit bien supportée. Je regarde aussi du coté de la Auzuntech X-Meridian 7.1 2G un peu moins chère, qui pourrait être suffisante pour 4 zones.
Il existe des appareils qui font tout ça out of box, mais le premier prix pour 4 zones commence à 3k3€… Avec interface proprio, et toutes les limitations qui vont avec.
Pour la facilité de manipulation, je compte caler ça dans des webservices qui pourront être appelé par différents type de terminaux. C'est un projet de longue haleine avec une grosse partie domotique, mais j'ai tout mon temps :)
Il faut surtout que la couche de routage audio soit pilotable logiciellement.
Je vais faire quelques tests avec pulseaudio.
Si l'admin fait les choses correctement, oui ça ne pose pas de problème.
Si il ne le fait pas, ça peut entrainer de grave problèmes.
Voici un exemple véridique:
Un admin débutant, pas très au courant des problèmes de sécu, à lancé un daemon teamspeak en root.
La version de teamspeak installée permettait à un attaquant de récupérer n'importe quel fichier local sur le serveur, avec donc les droits root.
Le mot de passe dans le fichier .p à donc donné un accès direct au root à l'attaquant, au lieu d’essayer de cracker le /etc/shadow en espérant que le mot de passe ne soit pas trop complexe.
C'est clairement une erreur grave de l'admin, mais la présence du .p facilite grandement le travail de piratage de la machine dans un cas comme celui-ci.
Il peut bien sur y avoir des failles du coté d'iptables/netfilter, mais dans le principe il vaut mieux que ce soit une machine sans données critique qui se prenne les attaques et effectue déjà un filtrage des type de paquets IP en provenance d'internet qui peuvent ensuite transité vers les machines critiques.
C'est déjà arrivé dans le passé qu'un simple PING forgé fasse planté l'OS sans possibilité de rattrapage des données. Rien ne prouve que cela ne puisse plus arriver.
On a aussi vu des backdoors positionnées dans un firmware de carte réseau par un attaquant, des failles dans les logiciels d'analyse réseau en mode promicious. Bref, toute machine auquel on a branché un câble réseau est potentiellement faillible, seul le degré de confiance compte.
Je préfère clairement que ce soit le firewall qui tombe que les machines derrière avec tout les risques que ça engendre.
Après si l'attaquant arrive a avoir un accès sur le firewall, il peut voir tout le trafic qui y transite, mais si il a réussit a pown cette machine, il y a de grandes chances que de toute façon il aurait eu accès à toutes les autres machines plus facilement.
Le risque est un problème dans l'OS et la pile IP, même si aucun port n'est ouvert.
Même un firewall peut laisser passer ça.
Je dirait plutôt qu'un firewall "en amont" de la machine est indispensable.
Outre le fait que ce soit Megaupload la victime et le débat que cela entraine sur la propriété intellectuelle, ce qui me révolte aujourd'hui, c'est que les États Unis ont détourné la résolution DNS non pas seulement aux états unis, mais dans le monde entier.
Hier un autre pays que celui dans lequel j'habite à décidé tout seul de ce que je pouvais affiché dans mon navigateur alors que les serveurs sont hébergés dans plusieurs parties du monde.
Que les États-Unis gèrent les serveurs racine DNS est peut être quelque chose d'historique, le principal était qu'on puisse leur faire confiance pour justement éviter que ce genre de choses n'arrive. Inutile de vous dire qu'aujourd'hui le peu de confiance que je leur accordai est réduit à néant.
Que ce soit pour la résolution DNS, du cloud hébergé chez eux, aujourd'hui j'ai vraiment peur pour l'avenir d'Internet.
Je sors certainement de mon rêve de l'Internet du pays des bisounours, mais ptain que le réveil est brutal et fait mal.
Connaissez vous un projet de dns décentralisé, même embryonnaire, qui ai besoin de petites mains prêtes à contribuer?
Finalement pour résoudre mon problème j'ai fait un petit outil en python.
Celui initialise un repo git dans un répertoire ~/.gitstore/data et créer automatiquement un repo sur bitbucket ayant comme nom l'host de la machine si le repo n’existe pas déjà, ou alors clone le repo si il est déjà présent.
Quand j'ajoute des fichiers ou répertoires grâce à l'outil, il copie les fichiers du système dans le repo et les ajoute à git.
Quand je demande une sauvegarde, il liste les fichiers contenus dans git et pour chaque fichier il vérifie si il correspond à celui présent sur le système.
Si le fichier est différent, il écrase celui dans git et si il n’existe plus il le supprime de git.
C'est clairement du bricolage, mais ça fait exactement le travail voulu.
Je peux donc créer un repo sur une nouvelle machine, ajouter des fichiers, traquer les modifications, push les fichiers modifiés.
Si je refait une machine existant déjà, cela clone les fichiers, et je peux choisir de les dispatcher sur le système un à un, ou de push directement les fichiers modifiés.
Il ne me reste plus qu'à broder quelques commandes pour lister les fichiers supprimés ou afficher un fichier d'une version donnée.
# Alias
Posté par lay . En réponse au message Nginx, directive location et ma question. Évalué à 3.
Bonjour,
Je penses qu'il faut que tu utilises la directive alias au lieu de root:
http://wiki.nginx.org/HttpCoreModule#alias
# MTU?
Posté par lay . En réponse au message OpenVPN lent CentOS 6.3. Évalué à 6. Dernière modification le 12 octobre 2012 à 17:18.
Bonjour,
Pour avoir un début de piste, essayes de regarder avec tcpdump sur le tunnel pour voir si la connexion TCP à travers le VPN a bonne allure et n'a pas de fragmentation.
Si il y a de la fragmentation, regardes du coté des réglages mtu, fragment ou mssfix dans le manuel d'openvpn, un mauvais réglage peut entrainer des problèmes du genre :)
[^] # Re: Une version binaire de Gentoo
Posté par lay . En réponse au journal Ma Gentoo... je t'adore mais.... Évalué à 6.
ArchLinux a-t-elle l'équivalent des use flags de Gentoo afin de limiter les dépendances inutiles?
C'est une vrai question car la feature de Gentoo qui me fait trouver fade tout autre distribution que j'ai testé :(
# Numéricable
Posté par lay . En réponse au message Kikala Fibre Optique ?. Évalué à 1.
J'ai l'offre "fibre" de Numéricable (bien sur c'est un simple coaxial) sur Rennes depuis plus de deux ans et j'en suis assez content.
Au niveau du débit maximum ça tourne vers 8.5Mo/sec et les coupures sont rares. Deux fois FT a coupé le câble pensant qu'il ne servait a rien…
Par contre j'ai aussi un abonnement free en adsl en dégroupage total, très lojn du DSLAM avec un débit très faible, et curieusement le ping sur la ligne ADSL est meilleur que celui de Numéricable.
Le service est OK dans l'ensemble, par contre gros point noir au tout début!
Lors de mon abonnement, ils m'ont installé une box 10Mb/s au lieu de celle à 100Mb/s, et franchement ils n'ont pas été très clair sur le sujet, entre l'installateur mal à l'aise une fois que je lui ai dit que j'étais dans le métier, le service client m'assurant que j'avais bien une box 100Mb/s, le vendeur en boutique qui était loin d'être surpris me donnant des excuses bidon. Si ça n'avait pas été la seule solution pour avoir du gros débit chez moi j'aurais été voir ailleurs dès que possible.
Passer cette épreuve, le service est pour ma part bien rendu.
# Pourquoi utiliser ifconfig?
Posté par lay . En réponse au message Gestion du réseau et des routes. Évalué à 3.
Bonjour,
La commande ifconfig n'utilise pas le fichier de configuration, ifconfig down eth0 va donc simplement supprimer eth0 sans faire quoique ce soit d'autre.
Ça ne m'étonne donc pas que ifdown ou ifup ne fonctionnent pas correctement ensuite car l'état de l'interface a été modifié entre temps.
N'utilises donc pas ifconfig mais plutôt les outils fournis par debian.
Pour ce qui est de la conf DNS, une solution serait de renseigner directement le fichier /etc/resolv.conf et ne pas mettre de dns-nameservers dans le fichier de config.
Mais tout ça est à prendre avec des pincettes, je ne suis pas utilisateur acharné de debian :)
[^] # Re: entres autres...
Posté par lay . En réponse au message Système de notification de problème hardware. Évalué à 0.
Alors la machine chez OVH est un peu tricky :)
Le système hôte est une gentoo à laquelle sont assignées 3 IP, une spécifique à l'admin, une pour l'utilisation perso, et une pour les invités.
L'hôte fait tourner des VM KVM sous debian, toutes reliées à un bridge réseau virtuel afin de créer un LAN interne, une des VM est spécialisée dans les services réseau du LAN interne tel que DHCP ou DNS en splited horizon. Ensuite en gros il y a une VM par service, tel quel mysql, une qui fait office de NAS qui exporte du nfs, samba, ftp avec pas mal d'espace, une pour tout ce qui est mail. Dans une VM il y a un nginx qui sert de frontal pour tout les sites de la machine, que ce soit pour la VM qui contient un apache pour plusieurs sites mutualisés ou alors pour des VMs invités. Il y en a une qui sert de serveur VPN pour que je puisse me connecter a partir de chez moi sur le LAN virtuel, acceder a samba ou nfs depuis mon poste, et une autre qui sert de passerelle réseau en partance vers un vpn en hollande (en fait chaque VM peut choisir si elle a accès a un internet par OVH ou part le VPN en choisissant la bonne passerelle dans sa conf réseau).
Pour tout ce qui est firewall et NAT sur l'hôte afin de faire fonctionner tout ça c'est du shorewall.
Bref ça fait tout un tas de services, c'est surtout pour faire joujou, il n'y a rien de critique qui tourne et en cas de problème seule ma fierté prendrait un coup auprès des invités :D
Mais en écrivant cela je me rend compte qu'il serait temps que je jettes un œil coté monitoring rien que pour avoir une vision plus claire.
[^] # Re: tu as le choix
Posté par lay . En réponse au message Système de notification de problème hardware. Évalué à 1. Dernière modification le 31 août 2012 à 22:38.
Je vais regarder du coté de smartmontools, qui, à moins que je me lances dans l'installation d'une usine à gaz, devrait être un bon début :)
[^] # Re: entres autres...
Posté par lay . En réponse au message Système de notification de problème hardware. Évalué à 1.
C'est un système qui commence à dater, je devrais le dépoussiérer un peu.
C'est un hôte gentoo qui fait tourner des vservers eux aussi sous gentoo (le proco n'a pas d'instructions VT…).
C'était vraiment très fun a l'installation mais un peu lourd à la longue :)
C'est la seule machine chez moi qui tourne en permanence et c'est un raid 1.
J'ai aussi un petit dédié chez OVH, et justement cette machine n'a pas de raid (question de budget), d’où ma demande d'un petit outil faisant le travail pour les disques, raids ou autres pièces.
A voir où il serait le plus judicieux d'installer le système de monitoring.
# Merci pour l'éclairage
Posté par lay . En réponse au message Système de notification de problème hardware. Évalué à 2.
J'ouvre une nouvelle file afin de vous répondre a tous.
D'abord merci pour vos réponses, cela me conforte dans le fait qu'il n'existe pas un petit daemon spécialisé capable de faire ça simplement sans déployer une solution de monitoring plus complexe, c'est un peu dommage car c'est utiliser pas mal de temps en déploiement pour un événement qui n'arrivera peut être jamais.
Il reste smartd qui fait le travail uniquement pour les disques dur.
Mais cela fait un petit moment que l'installation d'un nagios ou d'un shinken me démange, ce sera l’occasion de sauter le pas.
# Protocole?
Posté par lay . En réponse au message Conf ip6tables. Évalué à 8. Dernière modification le 28 août 2012 à 17:55.
Bonjour,
Je n'ai pas de quoi tester, mais n'as tu pas oublié de préciser le protocole utilisé afin qu'il puisse savoir de quel type de port il s'agit?
Exemple: -p tcp ou -p udp
# DNAT puis SNAT
Posté par lay . En réponse au message IPtables et NAT sous debian Squeeze. Évalué à 0.
Salut,
Premièrement tu configure ta box pour faire du DNAT vers ta debian sur le port 5000. Apparemment tu l'as déjà fait.
Le DNAT change seulement la destination du paquet, donc depuis l’extérieur tu aura accès a ta debian sur le port 5000, la debian verra arriver une connexion depuis l'IP de ton tel.
Ensuite sur la debian, il faut faire du SNAT sur le port 5000 en écoute pour rediriger le trafic vers ta caméra. Le SNAT change la source des paquets, donc ta camera verra une connexion depuis la debian alors que le paquet provient bien de ton tel. De cette manière même les paquets en retour passe par la débian, ce qui permet de maintenir l'état de la connexion et de te débarrasser de problèmes réseau.
Ensuite il faut que tu puisse laisser le trafic sur le port 5000 à la demande sur la debian. Pour ça il y à le port knocking qui répond à ton besoin.
Dans le principe une application sur ton tel essaye de se connecté a des ports bien précis chez toi, le daemon détecte la combinaison, et ajoute l'IP ayant fait la combinaison en white list un certain moment.
# Barre de recherche du navigateur
Posté par lay . En réponse au journal Google n'est pas mon ami !. Évalué à 1.
La barre de recherche de ton navigateur ne te convient-elle pas?
Elle est disponible dès le lancement du navigateur, n'utilise pas de javascript google et je n'ai jamais remarqué de problème d'ergonomie.
[^] # Re: Titre
Posté par lay . En réponse au journal 37% de Français croient au père Noël.. Évalué à 10.
Et moi je rajouterais que dans ma propre culture actuelle la religion a une crédibilité moindre et est surtout associé à la naïveté de certains adultes.
# Comment gérer l'interaction entre l'applicatif Web et la modification de ma configuration d'Apache?
Posté par lay . En réponse au message Développer un panel d'administration pour serveur dédié. Évalué à 1.
Pour que ce soit plus pratique tu peux déjà créer un dossier avec les droits de ton applicatif contenant un fichier de conf par virtualhost, chaque fichier de conf serait généré par ton applicatif.
Tu n'as plus qu'a inclure ce dossier depuis ton httpd.conf avec par exemple "Include virtualhosts/*.conf".
Pour relancer apache tu peux faire un script avec le bit Suid positionné, en faisant bien gaffe aux droits d’écriture sur le script. Cela permet de lancer le script en root si le script appartient à root.
Sinon pour faire un truc tip-top de la mort qui tue, je partirai personnellement vers des webservices qui font les actions de bases sur le système (par exemple un petit webserver en python), et une interface en php qui fait uniquement appel aux webservices pour faire le travail. Ainsi tu pourrais déployer les webservices sur plusieurs dédiés et avec une interface sur un seul dédié pour les centraliser.
Pour le risque de plantage au redémarrage d'apache qui entrainerai une perte de l'interface, une solution serait de mettre un nginx en frontal, qui sur un virtualhost afficherait le panel d'admin, et qui ferait un reverse proxy vers ton vrai apache pour tout les autres virtualhosts.
[^] # Re: Même projet
Posté par lay . En réponse au message Faisabilité d'un système de diffusion audio multizones et multisources. Évalué à 1. Dernière modification le 27 juillet 2012 à 12:26.
Salut,
C'est en effet deux projets pas très éloignés :)
Tu parles de sources numériques et analogiques, et justement en discutant avec un revendeur spécialiste de la Hi-Fi, il m'a proposé de partir sur une source numérique pour la pièce principale avec un DAC et du bon matériel de diffusion, et des sorties analogiques pour le reste des zones qui seront bien moins armées.
Mais il faut avant que je test la faisabilité, car ça implique du matériel hétérogène qui peut impacter une de mes contraintes qui est la synchronisation des différentes zones (autant mettre la barre haute dès le début :). Si ce n'est pas le cas, il faudra faire un choix entre la synchro et la qualité. Je m'interroge d’ailleurs sur la latence engendrée par des éléments sans fils.
Du coté software, nous avons des différences au niveau des sources, et ça entraine une différence d'approche dans la gestion du son. Comme toi je compte mettre différent type de sources :
- Un MPD, pour la radio et une bibliothèque locale. D'ailleurs tu m'apprends qu'il peut gérer plusieurs output, ça sera un gros avantage.
- Un client Spotify grâce à leur libsoptify.
- Un serveur airplay pour les iBidules.
- Un serveur Bluetooth pour les autres
- Etc
Mais avec autant de sources différentes je pense qu'il sera plus facile et plus maintenable d'unifier le routage du son dans une couche qui sera entre les logiciels de lecture et la carte son.
Voici donc un premier retour de mes tests, cela te donnera peut être des idées :)
Pour le moment je suis partit sur Jack, qui justement est spécialisé dans la connexion entre input et output de flux audio, et qui pour un début fait vraiment bien son travail. Après avoir fouiller les docs et les howto voici le principe:
J'ai choisis d'unifier les output des applis en utilisant le module snd_aloop d'alsa. Celui ci permet de créer des cartes son virtuelles, avec chacune 8 sorties. Ce module redirige simplement son input dans un output associé.
Dans asound.conf il faut créer pour chaque logiciel un PCM qui lui sera destiné et qui sera lié à une entrée de la carte virtuelle.
Chaque logiciel est donc configuré avec comme output le PCM qui lui est attribué. A partir de ce moment la, on a donc un moyen de lancer tout les logiciel pour lire de l'audio et de le sortir en utilisant uniquement alsa. On a un style d'output unifié :) Bien sur pour le moment les flux sont joués dans le vide.
Et la intervient Jack, qui va nous permettre de router à la volée les PCM virtuels vers les bonnes sorties de la carte son. Il permet de router le son d'un point A à un point B, et ceci dans n'importe quel sens et dans n'importe qu'elle combinaison, en faisant le mixing au passage si besoin. Pour que jack reconnaisse les canaux de la carte virtuelle il faut utiliser les outils alsa_input et alsa_output. L'interface qjackctl permet d'avoir une bonne vision du résultat de la chose.
Une fois que jack a en entrée les flux sortant des applis, il suffit de les mapper vers les bonnes sorties de la carte son, qu'il reconnait directement dans mon cas. Pour le moment je le fait manuellement, mais il il y à plusieur moyen de le piloter logiciellement :)
Voici mon premier POC et ça me donne pour le moment satisfaction.
Je suis ouvert à toutes idées, et niveau matos je n'ai pas encore bien regardé :-\
[^] # Re: Vous ici ?
Posté par lay . En réponse au message Faisabilité d'un système de diffusion audio multizones et multisources. Évalué à 2.
C'est un système qui pourrait fonctionner, au même titre que la solution DLNA proposée ci-dessus.
je l'ai d’ailleurs mis en place il a un bon moment pour faire de la diffusion sur un site web a partir d'une bibliothèque locale et ça fait bien le travail :)
Mais j'ai une contrainte forte aujourd'hui qui est la qualité du son arrivant aux amplis, que je veux le plus proche possible d'un signal Hi-Fi, proche du signal d'origine, afin de pouvoir profiter pleinement de bonnes enceintes au moins pour la pièce principale :)
Et c'est la que ça pêche, je ne pense pas qu'un petit système du genre raspberry pi soit capable de sortir un très bon signal, ou alors monter de petits systèmes avec une bonne carte son à chaque fois mais le budget en prendra un coup. J'ai regardé du coté des récepteurs dlna de grande marque de l'audio, et c'est hors de prix et c'est limité coté fonctionnalités.
De plus, plus je rajoute d'intermédiaires entre le la lecture du fichier et la sortie vers l'ampli, moins il y a de chance que le son soit proche de l'origine, et donc finalement plus de chance de me planter :)
C'est pour cela que je me suis dirigé vers un système unique, avec une seule carte son, moins de technologie différentes, qui est finalement un système plus simple et donc moins risqué. Bon il restera à tirer les cables :)
[^] # Re: Beau projet
Posté par lay . En réponse au message Faisabilité d'un système de diffusion audio multizones et multisources. Évalué à 1.
La PreSonus AudioBox 1818VSL m'a l'air un peu "overkill" pour débuter :) mais il est intéressant de voir que ce genre de matos existe.
Je vais attaquer la doc de jack, apparemment c'est une bonne solution.
Et apparemment il serait pilotable via dbus.
Merci pour vos infos :)
[^] # Re: DLNA, c'est fait pour ca
Posté par lay . En réponse au message Faisabilité d'un système de diffusion audio multizones et multisources. Évalué à 1.
C'est en effet une idée a creuser.
Mais ce qui me fait peur dans ce genre d'installation c'est :
- le risque de décalage du son entre plusieurs zones avec une seule source (buffers, latence réseau, etc), surtout que je peux pas tester sans avoir investit dans un minimum de matos.
- la qualité du son HI-FI pouvant être retranscrit comparé au système que j'ai proposé.
Mais c'est vrai que c'est une solution qui serait plus pratique.
[^] # Re: Beau projet
Posté par lay . En réponse au message Faisabilité d'un système de diffusion audio multizones et multisources. Évalué à 1.
Pour ce qui est de la carte son, justement la M-Audio delta 1010 fait partie de ma short list, content d'apprendre qu'elle soit bien supportée. Je regarde aussi du coté de la Auzuntech X-Meridian 7.1 2G un peu moins chère, qui pourrait être suffisante pour 4 zones.
Il existe des appareils qui font tout ça out of box, mais le premier prix pour 4 zones commence à 3k3€… Avec interface proprio, et toutes les limitations qui vont avec.
Pour la facilité de manipulation, je compte caler ça dans des webservices qui pourront être appelé par différents type de terminaux. C'est un projet de longue haleine avec une grosse partie domotique, mais j'ai tout mon temps :)
Il faut surtout que la couche de routage audio soit pilotable logiciellement.
Je vais faire quelques tests avec pulseaudio.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par lay . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 1.
Si l'admin fait les choses correctement, oui ça ne pose pas de problème.
Si il ne le fait pas, ça peut entrainer de grave problèmes.
Voici un exemple véridique:
Un admin débutant, pas très au courant des problèmes de sécu, à lancé un daemon teamspeak en root.
La version de teamspeak installée permettait à un attaquant de récupérer n'importe quel fichier local sur le serveur, avec donc les droits root.
Le mot de passe dans le fichier .p à donc donné un accès direct au root à l'attaquant, au lieu d’essayer de cracker le /etc/shadow en espérant que le mot de passe ne soit pas trop complexe.
C'est clairement une erreur grave de l'admin, mais la présence du .p facilite grandement le travail de piratage de la machine dans un cas comme celui-ci.
[^] # Re: Pourquoi attendre que la clef soit compromise ?
Posté par lay . En réponse au journal Compromission de clé SSH chez OVH. Évalué à 10.
Sans oublier le fichier /root/.p qui contient le mot de passe root…
[^] # Re: Firewall
Posté par lay . En réponse au journal J'ai plein d'amis ... et je ne le savais pas ;o). Évalué à 2. Dernière modification le 04 juin 2012 à 14:23.
Il peut bien sur y avoir des failles du coté d'iptables/netfilter, mais dans le principe il vaut mieux que ce soit une machine sans données critique qui se prenne les attaques et effectue déjà un filtrage des type de paquets IP en provenance d'internet qui peuvent ensuite transité vers les machines critiques.
C'est déjà arrivé dans le passé qu'un simple PING forgé fasse planté l'OS sans possibilité de rattrapage des données. Rien ne prouve que cela ne puisse plus arriver.
On a aussi vu des backdoors positionnées dans un firmware de carte réseau par un attaquant, des failles dans les logiciels d'analyse réseau en mode promicious. Bref, toute machine auquel on a branché un câble réseau est potentiellement faillible, seul le degré de confiance compte.
Je préfère clairement que ce soit le firewall qui tombe que les machines derrière avec tout les risques que ça engendre.
Après si l'attaquant arrive a avoir un accès sur le firewall, il peut voir tout le trafic qui y transite, mais si il a réussit a pown cette machine, il y a de grandes chances que de toute façon il aurait eu accès à toutes les autres machines plus facilement.
[^] # Re: Firewall
Posté par lay . En réponse au journal J'ai plein d'amis ... et je ne le savais pas ;o). Évalué à 4.
Le risque est un problème dans l'OS et la pile IP, même si aucun port n'est ouvert.
Même un firewall peut laisser passer ça.
Je dirait plutôt qu'un firewall "en amont" de la machine est indispensable.
# DNS, le talon d’Achille de l'Internet libre
Posté par lay . En réponse au journal Des limites de la propriété : pourquoi avoir fermé megaupload.com est un crime. Évalué à 10.
Outre le fait que ce soit Megaupload la victime et le débat que cela entraine sur la propriété intellectuelle, ce qui me révolte aujourd'hui, c'est que les États Unis ont détourné la résolution DNS non pas seulement aux états unis, mais dans le monde entier.
Hier un autre pays que celui dans lequel j'habite à décidé tout seul de ce que je pouvais affiché dans mon navigateur alors que les serveurs sont hébergés dans plusieurs parties du monde.
Que les États-Unis gèrent les serveurs racine DNS est peut être quelque chose d'historique, le principal était qu'on puisse leur faire confiance pour justement éviter que ce genre de choses n'arrive. Inutile de vous dire qu'aujourd'hui le peu de confiance que je leur accordai est réduit à néant.
Que ce soit pour la résolution DNS, du cloud hébergé chez eux, aujourd'hui j'ai vraiment peur pour l'avenir d'Internet.
Je sors certainement de mon rêve de l'Internet du pays des bisounours, mais ptain que le réveil est brutal et fait mal.
Connaissez vous un projet de dns décentralisé, même embryonnaire, qui ai besoin de petites mains prêtes à contribuer?
# Ça marche :)
Posté par lay . En réponse au message Système de gestion de version pour fichiers de configuration d'un serveur. Évalué à 1.
Finalement pour résoudre mon problème j'ai fait un petit outil en python.
Celui initialise un repo git dans un répertoire ~/.gitstore/data et créer automatiquement un repo sur bitbucket ayant comme nom l'host de la machine si le repo n’existe pas déjà, ou alors clone le repo si il est déjà présent.
Quand j'ajoute des fichiers ou répertoires grâce à l'outil, il copie les fichiers du système dans le repo et les ajoute à git.
Quand je demande une sauvegarde, il liste les fichiers contenus dans git et pour chaque fichier il vérifie si il correspond à celui présent sur le système.
Si le fichier est différent, il écrase celui dans git et si il n’existe plus il le supprime de git.
C'est clairement du bricolage, mais ça fait exactement le travail voulu.
Je peux donc créer un repo sur une nouvelle machine, ajouter des fichiers, traquer les modifications, push les fichiers modifiés.
Si je refait une machine existant déjà, cela clone les fichiers, et je peux choisir de les dispatcher sur le système un à un, ou de push directement les fichiers modifiés.
Il ne me reste plus qu'à broder quelques commandes pour lister les fichiers supprimés ou afficher un fichier d'une version donnée.
Merci à vous pour ces pistes :)