Journal En finir avec BIND et ProFTPD :)

Posté par Houbaa le 18 août 2004 à 04:00.

Étiquettes : aucune

août

2004

Dans un autre journal (http://linuxfr.org/~Houbaa/14858.html(...)) je me demandais sous quel OS passer mon routeur/serveur web. Après quelques hésitations, le choix s'est porté sur FreeBSD 5.2.1. Rien de particulier à dire sur la migration, cet OS est toujours d'aussi bonne qualité et facile (enfin... avec un peu de culture *NIX hein) d'installation.

J'en ai profité pour essayer deux trois projets qui ne m'ont pas déçu du tout.

* djbdns : l'alternative principale à BIND. Le serveur cache est complètement séparé du serveur DNS proprement dit, d'où plus de légèreté et plus de sécurité. Mais surtout, SURTOUT, deux heures en tout et pour tout pour installer la bête et écrire les fichiers de config ! Je préfère taire le temps que m'avait pris BIND ;)

http://cr.yp.to/djbdns.html(...) (le site est un peu austère mais bourré d'infos)

* PureFTPD : même principe ! J'en avais marre de ProFTPD et de sa lourdeur de configuration. Hop, PureFTPD, et en 30 minutes on se fait un beau serveur FTP avec TLS.

http://www.pureftpd.org/(...)

Je ne sais pas ce qu'il vaut par rapport au renommé VSFTPD (http://vsftpd.beasts.org/(...)). Si quelqu'un a utilisé les deux, j'aimerais bien en savoir plus...

* Apache : non là désolé j'ai rien trouvé de meilleur :o) Mais je tenais juste à faire un peu de pub pour cette petite merveille : mod_rewrite (http://httpd.apache.org/docs-2.0/mod/mod_rewrite.html(...)). Le principe est qu'Apache intercepte l'URL de la requête et la réécrit à travers une expression rationnelle avant de la servir. Jetez un coup d'oeil au site d'Apache pour voir à quoi ça peut servir.

Un autre truc d'Apache sur lequel j'ai percuté : beaucoup d'entre nous utilisent la combo Apache 2-mod_php4 sur leur site perso. Seulement Apache 2 tourne fréquemment en multi-threadé. Que va-t-il se passer si une des bibliothèques utilisées par PHP n'est pas thread-safe ? Perso j'ai pas envie de le savoir. Conclusion : pour plus de sureté, mettre Apache en prefork avec PHP...

* ipfw : c'est l'équivalent (actuel, ça va peut être changer pour Packet Filter) de Netfilter/iptables sous FreeBSD. Ben... waouhh !!! Même puissance que Netfilter, mais nettement plus facile d'écriture. En prime les scripts de base fournis sont assez complets et bien compréhensibles. À essayer sans hésitation si l'occasion se présente.

* PHP : là je dois dire que j'ai été un peu déçu. Je faisais tourner mon blog sur un Athlon 2.4GHz; inutile de dire que j'ai jamais eu de problème de rapidité. Mais sur un P2 300 MHz, ça devient une autre affaire : plusieurs secondes avant que la page principale du blog ne s'affiche (j'ai vérifié, c'est bien l'exécution du PHP qui bouffe ce temps). J'ai essayé d'accélérer un peu ça avec Turk MMCache (http://turck-mmcache.sourceforge.net/index_old.html(...)), mais ça n'améliore pas le temps d'exécution, seulement le temps de compilation. Le blog en question tourne sous Wordpress. Je suis en quête d'idées pour accélérer tout ça...

* Wordpress : mis à part le problème de rapidité précédent, sur une machine plus potable que la mienne, ce blog est une merveille. Facile d'installation, très respectueux des standards, assez riche, et modifiable si l'on touche un tant soit peu en PHP... Nombreux plugins disponibles. J'adore.

http://wordpress.org/(...)

Voili voilou, je vous encourage vivement à essayer ces quelques petits outils bien sympathiques et à donner votre avis !

# ...

Posté par BohwaZ (site web personnel, Mastodon) le 18 août 2004 à 05:42. Évalué à 2.

Question: as-tu mis PHP en module d'Apache?

Sinon tu peux essayer de trouver un truc qui génère les pages en HTML statique une fois pour toutes. L'astuce que j'ai déjà utilisé c'est un truc qui génère les pages HTML et le documenterror 404 redirige vers un script PHP qui va générer la page (si elle n'existe pas donc car 404). Evidemment après faut un système qui supprime les pages html si le contenu est modifié en php.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
- [^] # Re: ...
  
  Posté par Houbaa le 18 août 2004 à 06:22. Évalué à 0.
  
  Question: as-tu mis PHP en module d'Apache?
  
  Bien sûr.
  
  Sinon tu peux essayer de trouver un truc qui génère les pages en HTML statique une fois pour toutes.
  
  Oui :) Je me demande s'il existe déjà des scripts tout faits prêts à l'emploi. J'ai pas trop le temps d'aller hacker le code de Wordpress là...
  - [^] # Re: ...
    
    Posté par Krunch (site web personnel) le 18 août 2004 à 15:01. Évalué à 2.
    
    Pour la génération de pages HTML statique, moi j'aime bien WML mais c'est pas forcément adapté dans ce cas.
    
    http://thewml.org/(...)
    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# PHP et Apache2...

Posté par Guillaume Plessis (site web personnel) le 18 août 2004 à 08:03. Évalué à 3.

... c'est non!

Quoiqu'en disent les distribs qui ont le vent en poupe et autres fervents adeptes des toutes dernières versions de softs, Apache2 et PHP (4 ou 5), ce n'est même pas la peine d'y penser.

Une démonstration élégante, convaincante et exemple à l'appui par monsieur Rasmus Lerdorf :

http://marc.theaimsgroup.com/?l=php-dev&m=108736540021355(...)

A+

Gui
- [^] # Re: PHP et Apache2...
  
  Posté par Yannick Torrès le 18 août 2004 à 08:36. Évalué à 1.
  
  Et pour les anglophobes, voici l'entrée de la Faq de la documentation PHP en français reprenant l'email de Rasmus :
  
  http://fr3.php.net/manual/fr/faq.installation.php#faq.installation.(...)
- [^] # Re: PHP et Apache2...
  
  Posté par Frédéric Péters (site web personnel) le 18 août 2004 à 08:51. Évalué à 4.
  
  Comme écrit dans le journal, apache en prefork.
  
  Et comme écrit dans le mail cité: "And yes, you could use the prefork mpm with Apache2 to avoid the threading,".
- [^] # Re: PHP et Apache2...
  
  Posté par Nap le 18 août 2004 à 09:15. Évalué à 2.
  
  alors ma question : y a-t-il une architecture basée sur linux et apache 2 permettant de gérer un site web dynamique (bref, peut-on remplacer php...)
  - [^] # Re: PHP et Apache2...
    
    Posté par Jean-Baptiste Mayer le 18 août 2004 à 09:33. Évalué à 2.
    
    Tu peux tenter du jsp (Java servlet pages), avec un genre de JBoss ...
    - [^] # Re: PHP et Apache2...
      
      Posté par Calim' Héros (site web personnel) le 18 août 2004 à 11:20. Évalué à 1.
      
      ou tomcat :)
  - [^] # Re: PHP et Apache2...
    
    Posté par Yusei (Mastodon) le 18 août 2004 à 09:36. Évalué à 2.
    
    Il serait intéressant de voir si Perl/Python/Ruby se comportent mieux dans la même situation... pour ma part je préfère cent fois programmer en Ruby qu'en PHP, mais ce dernier est plus répandu chez les hébergeurs.
    - [^] # Re: PHP et Apache2...
      
      Posté par Olivier Grisel (site web personnel) le 18 août 2004 à 14:08. Évalué à 2.
      
      AMA, c'est le même problème puisque qu'une grande partie des modules/extensions de Perl/Python/Ruby et PHP sont basés sur les même librairies C en dessous. Si une lib écrite en C n'est pas thread safe, alors aucune des extensions Perl/Python/Ruby ou PHP basées dessus ne le deviendra par magie ...
      - [^] # Re: PHP et Apache2...
        
        Posté par Yusei (Mastodon) le 18 août 2004 à 16:51. Évalué à 2.
        
        J'me demande... vu que Ruby gère les threads, je pense que s'il y avait un problème au niveau des threads et des bibliothèques natives ça se saurait... Je ne pense donc pas que ruby incorporé dans apache pose plus de problème.
  - [^] # Re: PHP et Apache2...
    
    Posté par Thomas Hervé le 18 août 2004 à 09:55. Évalué à 2.
    
    Remplacer Php n'est pas évident... mais mod_python essaie de le faire au mieux ! J'ai commencé à tester des trucs dessus récemment, et en dehors du fait que je préfère largement le Python au Php, mod_python offre aussi des possibilités vraiment sympas et simples (l'utilisation de templates est super pratique).
    
    Il ya encore qq inconvénients : le mode de publication des pages n'est pas géniale (ou tu publies un dossier complet ou tu publies fichier par fichier), les sessions ne sont pas gérées aussi bien qu'en Php (ca s'améliore), et pendant le developpement d'un site il m'arrive souvent de devoir relancer apache2.
    
    Reste que tu bénéficies de toutes les librairies Python et bien sûr que cela fonctionne parfaitement en multi-threadé.
    
    http://www.modpython.org/(...)
    
    --
    Thomas
    - [^] # Re: PHP et Apache2...
      
      Posté par Nap le 18 août 2004 à 11:35. Évalué à 3.
      
      Reste que tu bénéficies de toutes les librairies Python et bien sûr que cela fonctionne parfaitement en multi-threadé.
      
      Justement, ils ont réellement tout réimplémenté ? Ils ne se basent sur aucune bibliothèque C foireuse ? Ca me surprend, par exemple pour postgresql...
      
      Idem pour Perl, ruby...
      - [^] # Re: PHP et Apache2...
        
        Posté par Thomas Hervé le 18 août 2004 à 13:48. Évalué à 1.
        
        Justement, ils ont réellement tout réimplémenté ? Ils ne se basent sur aucune bibliothèque C foireuse ? Ca me surprend, par exemple pour postgresql...
        
        Il existe plusieurs bibliothèques existantes pour Posgres, la seule que je connais (la plus utilisée ?) est Pygresql (http://www.pygresql.org/(...)) et elle est thread-safe depuis la version 3. En réalité je ne connais de bibliothèques "standards" qui ne soit pas thread-safe en Python; au pire la doc de chaque module donne ce type de renseignement.
        
        --
        Thomas
  - [^] # Re: PHP et Apache2...
    
    Posté par LaBienPensanceMaTuer le 18 août 2004 à 10:11. Évalué à 4.
    
    Moi je fais pas de PHP. Je fais des cgis ! En perl quand je suis pressé et en C quand j'ai le courage.
    Le contenu y a pas plus dynamique.
    Et depuis que j'utilise les CGIs en Perl pour mon site, j'ai les cheveux doux et brillants et l'haleine moins fétide.
  - [^] # Re: PHP et Apache2...
    
    Posté par Blackknight (site web personnel, Mastodon) le 18 août 2004 à 10:44. Évalué à 2.
    
    GNUstepWeb avec GDL2 ;-)
    Quelques petits liens :
    http://www.gnustep.org(...)
    http://www.gnustepweb.org(...) pas à jour
    
    Bon certes, il faut savoir programmer en Objective-C, connaître le framework GNUstep peut aider mais c'est assez sympa.
    
    Qu'est-ce que vous voulez, c'est ma période langage et framework exotiques !!!
    Ceci dit, ça marche bien mais c'est comme les EJB, c'est du serveur d'application plus qu'autre chose et ça peut paraitre démesuré.
# Proftpd, apache et wordpress.

Posté par frafra le 18 août 2004 à 10:07. Évalué à 4.

J'ai moi aussi abandonné Proftpd, mais au profit de vsftpd. La conf. "apache-like" de proftpd ne me dérange pas, c'est surtout les bugs réguliers et la difference de perfs qui m'ont fait changer. Dire que j'ai abandonné wu-ftpd pour Proftpd il y a 4 ans ... comme quoi en info il n'y a que des vérités instantanés.

En y reflechissant bien, je ne vois bien ce qu'apporte apache2. S'il faut désactiver le threading, et que la faq php déconseille apache2/php en prod. pourquoi vouloir à tout pris la dernière version qui lave plus blanc. Perso, je reste en 1.3 jusqu'a nouvel ordre.

Dernier point, as tu fais une recherche dans google, il me semble qu'il existe un cache pour wordpress. Mais je ne l'ai pas testé.
- [^] # Re: Proftpd, apache et wordpress.
  
  Posté par Houbaa le 18 août 2004 à 15:08. Évalué à 2.
  
  >Dernier point, as tu fais une recherche dans google, il me semble qu'il existe un cache pour wordpress. Mais je ne l'ai pas testé.
  
  http://photomatt.net/2004/07/26/staticize-25/(...)
  
  merchi :)
- [^] # Re: Proftpd, apache et wordpress.
  
  Posté par Houbaa le 18 août 2004 à 16:50. Évalué à 2.
  
  Ok, j'ai vu pourquoi Wordpress était si lent chez moi : la localisation en français passe par un mécanisme à la gettext en PHP. En le désactivant, ça va trois fois plus vite.
# squid ?

Posté par Benjamin (site web personnel) le 18 août 2004 à 10:09. Évalué à 7.

Salut,

bein si tu mets un squid en frontal de tout cela, bien tuné, cela te permettrait de ne pas calculer les pages à chaque visite et d'avoir donc un cache automatique de tes pages.

configure ton apache pour écouter sur 127.0.0.1:8080 par exemple, et dis à squid d'écouter sur 0.0.0.0:80 et d'être proxy/cache vers http://127.0.0.1:8080/(...)

@+

B
# add-ons

Posté par nullisimo le 18 août 2004 à 10:43. Évalué à 3.

"How to play with apache2 port" ;-)

Le port d'apache2 est principalement oriente 5-CURRENT, car depuis fevrier (post 5.2.1), il y a eu pas mal d'amelioration (kse par defaut, fine grained locking, etc...)
Pour les FreeBSD < 5.3, avoir un MPM threade est inutile (en fait si ca fonctionne c'est grace a un gros hack ;-)).
Chercher dans "FreeBSD" dans:
http://cvs.apache.org/viewcvs.cgi/httpd-2.0/STATUS(...)
Sous FreeBSD 5.2.1 tu peux toujours tester KSE et thr avec apache en definissant WITH_PTHREAD_LIBS={thr;kse} + WITH_MPM=worker (WITH_THREADS ajoute uniquement le support du threading dans apr).

Pour ceux qui veulent "accelerer" leur apache2 (sous FreeBSD):
1. Si la carte reseaux le supporte, ajouter "options DEVICE_POLLING" au kernel (man polling pour voir les cartes supportees)
2. ajouter comme knob lors du make WITH_EXPERIMENTAL_PATCHES. Ca rajoute le support pour kqueue + accf_http (*).
3. pour les + courageux ;) kldload sem (ou "options P1003_1B_SEMAPHORES") pour profiter de "posixsem" comme AcceptMutex (ca peut etre risque)
Rien qu'avec ca, sous haute charge, on peut esperer 40% de "perf" en plus ;-). (en fait ca reduit considerablement, les echanges userspace/kernelspace).

Une astuce (meme si ce n'est pas une solution) pour profiter d'un apache2 threade et de compiler php avec le support Fast_CGI (WITH_FASTCGI lors de la compil de php).

Un petit coup de coeur pour en finir avec apache ;-)
Pour ceux qui regrettent de ne pas avoir mod_accounting sous apache2, www/mod_log_config-st + www/mod_log_mysql peut le remplacer (en mieux meme ;-)

En ce qui concerne les demons FTP, il ya moftpd qui est pas trop mal.

(*) il existe l'equivalent sous linux (epoll), vous pouvez toujours recup les backport des patches (exp-apr-kqueue.patch) du ports pour test sous linux ;-)
- [^] # Re: add-ons
  
  Posté par duf le 18 août 2004 à 14:20. Évalué à 1.
  
  J'aurai juste une petite question, les optimisations que tu indiques pour accelerer apache2 sous FreeBSD tu les trouvés toi-même ou lus quelque part ? Dans ce dernier cas j'aimerai connaître si possible les références qui t'ont permis d'obtenir ces optimisations.
  
  Merci
  - [^] # Re: add-ons
    
    Posté par nullisimo le 18 août 2004 à 14:55. Évalué à 5.
    
    Je les ai testees moi-meme. J'ai fait toute une serie de benchmarks sur le port d'apache2.
    Tu as entre 40% et 65% de "boost" en plus, entre le apache2 "out-of-the-box" avec un kernel GENERIC, et ces 3 optimisations "simple".
    Sur un athlon XP 2000, 512Mo SDRAM, sur une carte mere Elite avec la carte reseau integre (sis), apache 2 avec MPM=worker.
    Avec httperf tu as:
    Out-of-the-box: 570 req/s
    Avec les points 1 et 2: 810 req/s
    avec le scheduler ULE, tu perds 5% compare au scheduler 4BSD. je n'ai pas teste avec les dernieres modifs de jeff roberson, mais ULE devrait au moins egaler 4BSD maintenant.
    Tu peux gagner 5-10 % avec posixsem (sous tres haute charge) et en modifiant le nb de threads max.
    Pour info ces tests ont ete realise avec le patch originel de Paul Querna, avant le cleanup explicite (a jour dans le patch), ce qui devrait eviter qq memory leaks et eviter au process "root" de nettoyer (tu peux donc esperer un gain significatif).
    Entre temps, la pile IP a ete nettoye (fine grained locking) donc apache devrait etre un peu plus reactif (niveau reseau).
    
    References:
    man accf_http
    man kqueue
    man polling
    http://httpd.apache.org/docs-2.0/misc/perf-tuning.html(...) (*)
    http://marc.theaimsgroup.com/?t=108650227500001&r=1&w=2(...)
    code source d'apache 2 ;-)
    
    (*): pour info "AcceptMutex pthread" sera supporte dans FreeBSD 6.x uniquement, car l'ajout pthread_mutexattr_setpshared() necessite un bump de la libc qui n'est plus possible depuis le code freeze de FreeBSD 5.0
    - [^] # Re: add-ons
      
      Posté par duf le 19 août 2004 à 23:54. Évalué à 1.
      
      Merci pour toutes ces informations.
# PureFTPD

Posté par Blackknight (site web personnel, Mastodon) le 18 août 2004 à 10:49. Évalué à 2.

Pourquoi avoir installé PureFTPD, le démon FTP de BSD te plaisait pas ?
- [^] # Re: PureFTPD
  
  Posté par Houbaa le 18 août 2004 à 16:45. Évalué à 2.
  
  Tout d'abord par curiosité, ensuite parce que le démon ftp de FreeBSD m'a paru un peu basique. Difficile tout de même de faire grand chose avec. Notamment, étant donné que le serveur tourne sur une machine accessible de l'extérieur (le royaume des méchants), l'authentification sécurisée est obligatoire.
  
  Cela dit, je n'ai jamais vraiment exploré ftpd. Il est peut-être très bien en fait.
  - [^] # Re: PureFTPD
    
    Posté par Blackknight (site web personnel, Mastodon) le 18 août 2004 à 18:04. Évalué à 1.
    
    Difficile tout de même de faire grand chose avec. Notamment, étant donné que le serveur tourne sur une machine accessible de l'extérieur (le royaume des méchants), l'authentification sécurisée est obligatoire.
    Bon, après tout dépend de ce que tu veux en faire.
    Ceci dit regardes bien la page de man car pour ce qui est de l'authentification, le système en lui-même fournit déjà pas mal de choses que le FTPD utilise (notamment, tout ce qui a trait au login.conf). Le gros avantage de cette méthode est que l'administration d'un compte utilisateur ne se fait qu'à un endroit précis. Son gros inconvénient, c'est que pour un compte utilisateur, tout se fait à un seul endroit ;-) (Si par exemple, tu veux empêcher le login ssh entre 21h et 8h mais que tu veux autoriser le ftp sur cette plage).
    Je peux pas te dire beaucoup plus de trucs que ça vu que je n'ai qu'une 4.7 sous la main et qu'il me semble que certaines choses ont changé depuis.
# VSftpd

Posté par un_brice (site web personnel) le 18 août 2004 à 11:56. Évalué à 2.

Il existe également un autre démon FTP très intéressant: VSftpd (Very Secure ftpd) qui, grâce à une architecture simple et un ensemble de fonctionalités bien choisies à réussi à ne pas souffir d'une faille en 3 ans, et ce avec un excellent niveau de performances.
http://vsftpd.beasts.org/(...)
# Question bete...

Posté par Calim' Héros (site web personnel) le 18 août 2004 à 12:11. Évalué à 1.

C'est quoi leur equivalent d'apt-get ou de rpm, enfin le truc qui permet de mettre a jour facilement surtout en cas de faille de securité?
- [^] # Re: Question bete...
  
  Posté par nullisimo le 18 août 2004 à 12:16. Évalué à 3.
  
  portupgrade ;-)
  # cd /usr/ports/sysutils/portupgrade
  # make install clean
  
  pour bien debuter :
  http://www.onlamp.com/pub/a/bsd/2003/08/28/FreeBSD_Basics.html(...)
- [^] # Re: Question bete...
  
  Posté par Houbaa le 18 août 2004 à 14:38. Évalué à 3.
  
  Pour les installations de logiciels, il y a portupgrade. Globalement l'outil est très très semblable au "emerge" de gentoo (emerge est de fait parti du système de ports de freebsd).
  
  Pour les failles "système" (noyau et logiciels associés : sur BSD, le "système" comprend le noyau plus les outils GNU traditionnels, BIND, ...) on peut patcher directement les binaires avec freebsd-update. Sinon il reste la mise à jour de l'arbre des sources et la recompilation, ce qui est envisageable sur une config rapide.
  - [^] # Re: Question bete...
    
    Posté par Calim' Héros (site web personnel) le 18 août 2004 à 14:47. Évalué à 1.
    
    Ca serait plus pour un celeron 500 destiné a faire firewall/routeur avec d'un coté mon reseau et de l'autre ma freebox. Comme cette machine n'est tjs pas configuré je suis en train d'envisager la possibilité face a une debian sarge
    - [^] # Re: Question bete...
      
      Posté par Houbaa le 18 août 2004 à 16:49. Évalué à 2.
      
      Très sincèrement FreeBSD et Debian sont de qualités équivalentes pour un serveur. C'est surtout une affaire de goût. Si tu as un peu de temps et de la curiosité, FreeBSD vaut le détour. Si tu as l'habitude de debian et que tu souhaites mettre en place une solution rapidement, opte pour Debian...
      
      La vitesse de ton processeur en tout cas n'est pas un handicap pour maintenir ta machine à jour sous *BSD.
      - [^] # Re: Question bete...
        
        Posté par Calim' Héros (site web personnel) le 18 août 2004 à 17:57. Évalué à 1.
        
        Le truc c'est que j'ai deja fait du firewalling et du nat sous freeBSD 4x mais je n'en ai jamais installé et j'ai deja installé du debian mais jamais fait de firewalling avec. Alors je me documente sur les 2 :)
# bind VS djb

Posté par gc (site web personnel) le 18 août 2004 à 12:30. Évalué à 5.

Je signale juste au passage que Bind est libre, alors que djbdns est un produit DJB et comme tout bon produit DJB il n'est pas libre.
- [^] # Re: bind VS djb
  
  Posté par Krunch (site web personnel) le 18 août 2004 à 14:58. Évalué à 3.
  
  J'ajouterais que je ne comprends pas trop les reproches de "difficultés de configuration" qui sont fait à BIND. J'ai appris à l'utiliser il n'y a pas un mois et écrire ses fichiers de zone et de configuration n'a rien de bien compliqué. Comme toujours il suffit de bien RTFM.
  
  D'un autre côté j'ai jamais essayé djbdns et les problèmes de sécurité et d'architecture de BIND semblent reconnus de tous.
  pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
- [^] # Re: bind VS djb
  
  Posté par Aurélien Bompard (site web personnel) le 19 août 2004 à 09:20. Évalué à 2.
  
  Il me semble même qu'il n'est pas open-source, selon la définition de l'OSI. Tu as la source, mais tu peux pas recompiler et distribuer le binaire. En tout cas DJB avoue lui-même que qmail n'est pas open-source.
  - [^] # Re: bind VS djb
    
    Posté par Calim' Héros (site web personnel) le 19 août 2004 à 10:29. Évalué à 1.
    
    Il me semble avoir lu dans le linux mag de mars (+/- 1 moi) que l'auteur en faisait expres de le laisser comme ca. Ca rend impossible (legalement parlant) la modification du source, obliger de faire des patchs qui eux sont distribuable selon la licence que qouhaite leur auteur.
  - [^] # Re: bind VS djb
    
    Posté par Houbaa le 19 août 2004 à 10:51. Évalué à 2.
    
    Les logiciels djb sont distribués, si je ne me trompe pas, sans license, donc protégés par le droit d'auteur. Les sources sont disponibles. On peut les modifier, les recompiler chez soi, mais on ne peut redistribuer des sources ou un binaire modifiés. L'intérêt pour l'auteur est de garder un total contrôle sur son produit et son évolution.
    
    Mais j'espère bien que les lecteurs de linuxfr ne sont pas des intégristes du logiciel libre, spa ? ;-)
    - [^] # Re: bind VS djb
      
      Posté par Calim' Héros (site web personnel) le 19 août 2004 à 11:22. Évalué à 1.
      
      Tu esperes bien, ils sont juste desintegriste du logiciel propriétaire :p

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.