matiasf a écrit 1969 commentaires

> Ca n'a rien à voir !
OK j'y connais pas grand chose...

> http://www.businessweek.com/technology/content/(...)
Bon, ben ... t'as raison.

Il me semblait avoir lu sur lwn.net il y a 1/2 mois environ que RedHat n'avait pas fait de bénéfice pour les deux premiers trimestre de 2002 et que l'explication était les pertes (assez importantes) liées de leur département l'embarqué.

> Oui mais qui met encore à jour ses stats perso sur linux counter ?
Ben moi.
Non, plus sérieusement, je suis inscrit depuis longtemps et j'ai mis à jour il y a 8 mois environ (changement de hardware).

Néanmoins le site est toujours renseigné. Le nombre de machine/utilisateur continu de croitre en 2002. De plus, si je prend par exemple la moyenne de la ram utilisée j'ai 50 % de 128 à 256 Mo. Ce qui semble grosso-modo l'état actuel du parc. Selon moi c'est la source la plus sure. Par contre le site n'est pas assez maintenu. En effet 65 % des cpu sont classé dans "autre" (il n'y a rien de proposé au-dessus de 1Ghz).
Remarques de 30% pour RedHat ce n'est pas les 50% que j'ai lu dans certains articles. Et que 19 % pour Mandrake est plus qu'honorable. Mandrake est moins ancien que RedHat et est une boîte de taille nettement plus faible. Le chiffre de 30% pour RedHat ne me semble pas abérant.

> Ce n'est pas un secret ! Ils ont plus en cash que ce qu'ils gagnet (grâce à cette introduction en bourse de 1999...!)

Ce n'est pas un secret car RH fourni sur leur site web les rapports financier :
http://www.corporate-ir.net/ireye/ir_site.zhtml?ticker=RHAT&scr(...)

RedHat (la société car certains dirigeants sont assez blindés...) n'a pas des tonnes de cash. A l'introduction en bourse la côte a été multiplié par 3. Mais depuis ce sommet, la côte de RedHat a été divisé par 20.

> > http://counter.li.org/(...)
> c'est un vieux truc.

Le site est vieux mais les statistiques non. Selon le site la dernier stat date de :
Generated: Tue Dec 3 19:26:58 2002

Bref aujourd'hui.

> [des sondages en ligne ou équivalent]

C.f. juste au-dessus l'excellent post de "Houba houba Hop !" (C'est un cri de guerre ou un orgasme ce "Houba..." ).

Chez moi çà marche (athlon XP, KT266).

> des reserves de centaines de millions de $ en caisse depuis cette intro en bourse.
Je suis pas sure mais je doute beaucoup. Selon mes connaissance RedHat n'est pas encore à l'équilibre bien qu'il s'en approche.

> ils sont 2x plus téléchargés que RH.
Ben il faut que les mandrakiens fonce sur http://counter.li.org/(...) car ce n'est pas ce qu'indique les statistiques :
Mdk : 19 %
RH : 30 %

Leur offre est pour l'achat d'une mdk 8.1 ou 8.2. Je ne comprend pas pourquoi il ne propose pas la 9.0.

Il y a un côté "liquidation des stocks".

Mais c'est une bonne initiative et qui "risque" de faire école.

Ils font du code GPL. Ils contribuent et leurs contributions se voient, influencent le projet. C'est normal.

Tu préfères qu'ils dépensent leur ressource en programme propriétaire ? Mais j'aime bien savoir que des gens sont payé pour faire du GPL.

> J'espere que c'est ironique ???
Non.

> d'aller voir le code pour te faire une idee reelle des "si bons programmes" .

Le programme bind est utilisé ? OUI ou NON
OUI.
Il marche bien ? OUI ou NON
OUI
Il donne satisfaction ? OUI ou NON
OUI
Il est free software ? OUI ou NON
OUI

C'est un bon programme.
S'il est mal codé c'est une autre histoire. Je ne connais pas la qualité du code puisque que je ne l'ai pas regardé et je peux admettre qu'il est mal codé. Mais c'est un bon programme !
Moi je vois qu'il y en a plein qui se la pête hackers avec "code crade", etc... sous-entendu qu'il peuvent faire mieux et que c'est une honte de faire du code comme çà.
Vous me faites rire. Comment ce fait-il que toutes ces pointures n'ont pas fait un bon remplaçant à bind ? surtout que bind c'est "vieux".
Que font ces pointures ?
Elles utilisent Bind car çà les faient chier de coder un nouveau Bind.
Chers pointures qui utilisés Bind, reconnaissez que c'est un bon programme. Sinon codé un remplaçant !
Et meilleur puisque vous avez cette prétention.

PS : Je ne dis pas çà à ceux qui ne critique QUE la qualité du code (si c'est vrai :-o )

> Ce que tu ne comprends pas c'est meme si le chroot n'empeche pas la faille ,
Je le sais. Mais il y a plein de truc à s'occuper avant d'en arrivé là...

> il a au moins le merite de limiter les degats
La meilleur façon de limité les degats est d'avoir un bon backup...
Les backup ont en parle jamais ici alors que c'est le truc le plus important !

> tu dois pouvoir appliquer les quotas de groupe
Mouais. mais c'est un peu tordu. L'utilisateur devient le group et le group l'utilisateur.

> si ça marche - jamais essayé
les quota sur groupe marche.

> et en réglant leur umask à 002.
007 puisque les fichiers créés ont uid=apache.

> je parle du compte Web, pas spécifiquement de /home/user
Oublie le HOME. En général pour un site web j'ai :
- /home/www/toto : çà c'est pour le développeur (stockage de doc, etc...)
- /var/www/html/toto : çà c'est le site web. apache n'utilise jamais /home/www/toto (sauf avec user_dir).
- /var/www/data/toto : upload, statistiques, etc... Tout ce qui est dynamique. C'est ici que je pourrai faire le chmod g+s .

> Sur ce point précis

Malheureusement...
J'avais déjà étudié cette possibilité... et je l'utilise pour mysql. Elle est intéressante pour les sites où le client ne peut déposer de fichiers php (il n'est pas le développeur). Mais c'est cool pour les sites avec statistique et/ou upload.

> Enfin, je trouve que c'est domage de descendre une release
> c'est manquer un peu de respect pour le travail formidable de l'équipe de PG

Je ne croix pas que c'est son intention. Il a un problème de perfo et indique qu'il va se pencher sur la question. Il a aussi quelques problèmes liés à la suppression de datetime (problème qu'il a corrigé). Il n'en fait pas reproche, il le constate uniquement.

Il faut pas oublié que les utilisateurs d'un logiciel (semble-t-il de longue date dans ce cas) ne vont pas descendre le logiciel pour le plaisir. Néanmoins il doit pouvoir faire part de ses déconvenus. Et c'est uniquement ce qu'il a fait.

PS : j'aime bien PostgreSQL.

> plus rarement mais plus grave me griller mon disque dur ou ma carte mère.
très, très, très, très, très rarement...

> mais on n'a pas forcément une machine à casser.
Ben tu peux avoir un disque dur pour les tests.

Moins j'ai un disque dur de "production" et un de backup. Pour les tests risqués je les fais sur le disque de backup. Une foi le test terminé, je refais un backup (avec rsync).

Tant pis pour moi. J'espérai tomber sur quelqu'un qui avais le même problème que moi. Merci pour ton essai.

> Heu, t'as mal foutu ton truc alors.

Je crois que tu n'as pas bien compris.

Ta méthode marche mais elle ne répond pas à tout le problème :
1 - c'est toi qui gère les scrips cgi du client.. Dans mon cas, je peux laisser le client faire ces scripts cgi (puisqu'il a son propre compte).
2 - tu ne peux pas appliquer les quotas dans ton cas (n'oublies que les uploads sont dans le compte apache dans ton cas). Ce point est très important si le client à un acces en écriture via ftp par exemple ou s'il peut modifier les scripts php ou s'il peut réaliser des uploads etc, etc, ...
3 - dans ton cas, tu ne peux pas raisonnablement autoriser des binaires fournis par le client.

De plus si j'utilise les acl (c'est un domaine que je dois creuser) je peux authoriser ssh et donc les crontabs, les mysql_dump, etc, etc... j'autorise ssh uniquement avec acl sinon il est vraiment trop simple pour le client de voir les fichiers des autres sites (même ceux qui sont protégés via http par un fichier .htaccess).
Sinon, si les acl ne repondent pas au problème, je peux faire une conf d'apache mini (et minucieusement audité) qui troune sous le compte root et mettre les fichiers des sites non lisible pour les autres.

Les systèmes de sécurité de php sont satisfesants dans beaucoup de cas. Néanmoins pour les exisgences de certains clients suexec peut être indispensable.

> pas dans leur $HOME quoi !
$HOME n'est pas forcément utilisé par suexec.
Exemple :
<VirtualHost>
ServerName www.toto.com
User toto
Group website
DocumentRoot /var/www/html/www.toto.com/site/
php_flag engine off
AddHandler php-script .php
Action php-script /cgi-bin-local/php
ScriptAlias /cgi-bin-local/php "/var/www/html/www.toto.com/cgi-bin-local/php"
[...]
</VirtualHost>
Le site www.toto.com tourne sous le compte toto (les cgi du moins, il faut donc désactiver mod_php pour ce site et utilisé php en cgi).
/var/www/html/www.toto.com/cgi-bin-local/php est tout con :
#!/bin/bash
exec php $*

L'intérêt de ce petit wrapper est que le fichier php.ini utilisé par php est /var/www/html/www.toto.com/cgi-bin-local/php.ini. Ce qui permet de configurer php en fonction du site (ou du répertoire, etc...). Le problème est que les directives php_* dans httpd.conf ne marche pas pour php en cgi.

Le $HOME de toto peut être /home/toto. çà n'a aucune importance.

Par contre $HOME est utilisé lors de l'utilisation de UserDir :
UserDir public_html

http://127.0.0.1/~toto/(...) => /home/toto/public_html/

Les scripts cgi tourne sous le compte toto (si suexec est installé).

Enfin, on peut ausi appliquer suexec par répertoire (ici http://hostname/www.toto.com/(...) ):
ProxyPass /www.toto.com/ http://www.toto.com.localhost/(...)
ProxyPassReverse /www.toto.com/ http://www.toto.com.localhost/(...)

L'ip de www.toto.com.localhost est 127.0.0.1.
Il reste à définir le virtual host www.toto.com.localhost (évidament non accessible de l'extérieur) comme fait au-dessus.

PS : Il existe d'autre solutions que suexec...

> Maintenant, plutôt que cracher sur Bind, XFree86 ou d'autres logiciels
Faudrait déjà les remercier d'avoir développer en freesoftware de si bon programmes. Bind a rendu et rend toujours d'énormes services et ce de façon fiable et sous licence BSD-like.

Merci Messieurs et Mesdame (s'il y en a) !

> Quand ils se disputent on a toujours 3 à 3 ou 4 articles, 500 commentaires sur /.

Ta remarque est d'autant plus pertinante que cette bonne nouvelle passe en seconde page alors que les coups de kanif de certains developpeurs aigri passent en première page.

Ouais ben moi ce que je vois c'est que KDE va pomper sans scrupule le boulot réalisé par GNOME car il prennent du retard et que se sont de gros branleurs. Ils me font pitié. Déjà qu'ils ne savent développer quand C++ et que leur première source d'inspiration (si on peut parlé d'inspiration...) est windows.

Putain merde quoi !
Si KDE et GNOME marchent la main dans la main c'est en fini des poilades avec des gros trolls. Déjà que RedHat fourni de leur bande passante pour certains sites web de KDE.
Moi je vous le dit : Tout fout le camp ! il n'y a plus que des chiffes molles !

> Il me semble qu'Apache déconseille l'utilisation de suexec.
QUOI !?!?

Extrait de la doc (http://httpd.apache.org/docs/suexec.html(...)) :
-------------------
Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer's security. If you aren't familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.
--------------------

En gros c'est du bon matos mais mal configuré çà peut être une merde.

> Pour PHP il vaut mieux utiliser les protections fournies avec (safe_mode, open_basedir)
Le problème est que ces protections son assez facilement contournables dans certain cas.

Exemple :
Je veux permettre à l'internaute d'uploader des .tgz et de les désarchiver.
Je met le fichier untargz.sh dans l'arborescence du site :

#!/bin/bash
cat $1 | gzip -d | tar xf -

puis je l'exécute avec php avec :

exec("scripts/untargz.sh /tmp/upload.tgz" , $output, $ret) ;

çà marche même avec safe_mode et open_basedir. C'est tant mieux vu l'énoncé du problème.

Maintenant j'autorise mon client a modifier les scripts php de son site (bref il devient le développeur du site). Le client, ou un cracker qui a eu connaissance du mot de passe du compte ftp qui permet de modifier le site, met dans le untargz.sh "rm -r -f /". çà marche toujours très bien.
Si j'utilise suexec les dégats seront limités au compte du site. Si je n'utilise pas suexec (donc j'ai le même compte pour tous les sites hébergés puisque qu'apache ne change pas de compte) ben je peux detruire tous les sites !

L'autre avantage d'utiliser suexec est la possibilité de mettre des quotas par site (chaque site ayant son compte Unix). Ainsi si un site peut-être modifié par un client via ftp, il ne peut pas saturer les disques (ce qui serait dramatique pour le bon fonctionnement du serveur).

Le seul problème de ce type de solution est que les fichiers servies par apache doivent être lisible par apache (lecture pour le compte apache). Donc les fichiers des sites web (qui ont chaqu'un un compte spécifique) doivent être en lecture pour tout le monde (ou au moins pour le groupe apache, mais dans ce cas, mes comptes font aussi parti du groupe apache). Donc dans mon cas d'utilisation de suexec il y a possibilité de lire tous les fichiers des autres sites (mais pas de les modifiers).
La bonne solution serait peut-être d'utiliser les ACL . Mais là j'y connais pas grand chose...

> écrire sur le disque les buffers "sales" en mémoire

J'utiliserai jamais sync. Il est hors de question que l'OS me foute des trucs "sales" de la mémoire sur mon disque.
J'ai dit !

Pour ceux qui ne parle pas courament le "^", 2^15 c'est 1 suivi de 15 zero en binaire. Soit 1 000 000 000 000 000. Ou en decimal 32 768 . Notons que l'emploi d'expression comme 2^15 est vivement encouragé sur l'Internet. En effet "2^15" utilise 2 caractères de moins que "32 768" et çà permet de sauver une bande passante précieuse permettant ainsi aux c0wb0yz de base du web de downloader comme des ouf des mp3 et des xxx cum fuck amateur hot.avi.

PS:
Une définition précise de "c0wb0yz de base du web" peut-être trouvé ici :
http://membres.lycos.fr/azerty0/(...)

çà fait du bien de rire.
Je te donne un [+], c'est cadeau.

> Pour qu'Apache supporte user_dir il doit être root
Je veux dire pour qu'Apache supporte user_dir avec des scripts cgi qui sont lancé avec le compte accédé. Cette fonctionnalité marche de paire avec suexec et suexec peut marché par virtual host.
Exemple :
http://qqpart/~toto/index.php(...)
index.php est lancé en cgi avec les privilèges du compte toto.
Ce qui est plus sure surtout si toto peut déposer des scripts php via ftp par exemple. Si le mot de passe du compte toto est connu par un cracker, les scripts déposés par le cracker seront limités aux possibilités du compte toto.

La peur de la délinquance de TF1 est sur linuxfr :-) .

Je ne comprends pas. Un petit commentaire pour éclairer ma lanterne.

> on peut penser que FM ...
Merci, c'est exactement çà.

> Les source bind founit par isc n'est pas libre?
> Les sources ne peuvent par etre modifier par la communotée?

Rien de tout çà. Les gens ont peur. C'est l'effet 21 avril.