Je souhaite une distrib light, en gros uniquement avec ce qu'il faut
pour faire tourner la machine sans soft supplémentaire (et surtout sans
X) avec à la limite gcc pour pouvoir compiler d'autres softs (sachant
que ça doit pouvoir gérer des biproc xeon en hyperthreading avec du raid
5 en SAS).
Toutes les distribs que j'ai installe au minimum 300Mo de packages en
tout genre. Quelqu'un pourrait me dire vers quoi me tourner ?
Autre petite question... Y a t'il des différences de rapidité entre les
différentes ditribs Linux ?
Et pourquoi faudrait il obligatoirement les fabriquer sur une autre machine ? Quel est l'interet de s'interdire l'utilisation d'un compilateur sur cette machine ? Règle de sécurité N°1 : ne rien avoir qui ne soit nécessaire. Tous
les ports fermés, sauf ceux liés aux services fournis. Tous les processus non liés au service fourni arrêté. Toutes les applis non liées aux services fournies désinstallées. Tu minimises ainsi les failles de sécurité et les risques de panne.
à qoui sert un firewall ?
ceinture + bretelles.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
moi@moi.org writes:
Et pourquoi faudrait il obligatoirement les fabriquer sur une autre
machine ? Quel est l'interet de s'interdire l'utilisation d'un compilateur
sur cette machine ?
Règle de sécurité N°1 : ne rien avoir qui ne soit nécessaire. Tous
les ports fermés, sauf ceux liés aux services fournis. Tous les
processus non liés au service fourni arrêté. Toutes les applis non
liées aux services fournies désinstallées. Tu minimises ainsi les
failles de sécurité et les risques de panne.
à qoui sert un firewall ?
ceinture + bretelles.
MB
--
Michel BILLAUD billaud@labri.fr
LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792
351, cours de la Libération http://www.labri.fr/~billaud
33405 Talence (FRANCE)
Et pourquoi faudrait il obligatoirement les fabriquer sur une autre machine ? Quel est l'interet de s'interdire l'utilisation d'un compilateur sur cette machine ? Règle de sécurité N°1 : ne rien avoir qui ne soit nécessaire. Tous
les ports fermés, sauf ceux liés aux services fournis. Tous les processus non liés au service fourni arrêté. Toutes les applis non liées aux services fournies désinstallées. Tu minimises ainsi les failles de sécurité et les risques de panne.
à qoui sert un firewall ?
ceinture + bretelles.
MB
-- Michel BILLAUD LABRI-Université Bordeaux I tel 05 4000 6922 / 05 5684 5792 351, cours de la Libération http://www.labri.fr/~billaud 33405 Talence (FRANCE)
sansflotusspam
Thierry Boudet wrote:
On 2006-12-21, wrote:
Le mieux c'est d'installer un FreeBSD, comme fait Microsoft d'ailleurs
Elle existe encore, cette légende ?
quelle légende ? il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et qu'ils maquillent l'identifiant en NTxxxx ! et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code BSD, quasiment toute la pile TCP/IP, par exemple. ça fait 20 ans que Micro$oft court après Unix, sans le rattraper bien sûr. les légendes, elles sont à Redmond.
Thierry Boudet wrote:
On 2006-12-21, moi@moi.org <moi@moi.org> wrote:
Le mieux c'est d'installer un FreeBSD, comme fait Microsoft d'ailleurs
Elle existe encore, cette légende ?
quelle légende ?
il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et
qu'ils maquillent l'identifiant en NTxxxx !
et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code
BSD, quasiment toute la pile TCP/IP, par exemple.
ça fait 20 ans que Micro$oft court après Unix, sans le rattraper bien sûr.
les légendes, elles sont à Redmond.
Le mieux c'est d'installer un FreeBSD, comme fait Microsoft d'ailleurs
Elle existe encore, cette légende ?
quelle légende ? il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et qu'ils maquillent l'identifiant en NTxxxx ! et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code BSD, quasiment toute la pile TCP/IP, par exemple. ça fait 20 ans que Micro$oft court après Unix, sans le rattraper bien sûr. les légendes, elles sont à Redmond.
Nicolas George
sansflotusspam , dans le message <458ada01$0$8161$, a écrit :
il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et qu'ils maquillent l'identifiant en NTxxxx ! et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code BSD, quasiment toute la pile TCP/IP, par exemple.
Hum. Tel que je le connaissais, c'est que (1) les serveurs de _Hotmail_ sont longtemps restés sous _Free_BSD derrière un frontal (et pas simplement un maquillage) NT, et que la pile réseau de la série des 9x venait de BSD, mais que celle de 00 au moins avait été ré-écrite.
sansflotusspam , dans le message
<458ada01$0$8161$426a34cc@news.free.fr>, a écrit :
il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et
qu'ils maquillent l'identifiant en NTxxxx !
et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code
BSD, quasiment toute la pile TCP/IP, par exemple.
Hum. Tel que je le connaissais, c'est que (1) les serveurs de _Hotmail_ sont
longtemps restés sous _Free_BSD derrière un frontal (et pas simplement un
maquillage) NT, et que la pile réseau de la série des 9x venait de BSD, mais
que celle de 00 au moins avait été ré-écrite.
sansflotusspam , dans le message <458ada01$0$8161$, a écrit :
il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et qu'ils maquillent l'identifiant en NTxxxx ! et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code BSD, quasiment toute la pile TCP/IP, par exemple.
Hum. Tel que je le connaissais, c'est que (1) les serveurs de _Hotmail_ sont longtemps restés sous _Free_BSD derrière un frontal (et pas simplement un maquillage) NT, et que la pile réseau de la série des 9x venait de BSD, mais que celle de 00 au moins avait été ré-écrite.
moi
On 2006-12-21, wrote:
Le mieux c'est d'installer un FreeBSD, comme fait Microsoft d'ailleurs
Elle existe encore, cette légende ?
Chut !!!
On 2006-12-21, moi@moi.org <moi@moi.org> wrote:
Le mieux c'est d'installer un FreeBSD, comme fait Microsoft d'ailleurs
Le mieux c'est d'installer un FreeBSD, comme fait Microsoft d'ailleurs
Elle existe encore, cette légende ?
Chut !!!
moi
À faire croire au décideur pressé que son réseau est totalement secure, alors que si une seule machine est compromise via un port ouvert, tout le reste du réseau est exposé.
Non, je m'inscrit en faux. Les machines éteintes ont les ports fermés
À faire croire au décideur pressé que son réseau est totalement secure,
alors que si une seule machine est compromise via un port ouvert, tout
le reste du réseau est exposé.
Non, je m'inscrit en faux. Les machines éteintes ont les ports fermés
À faire croire au décideur pressé que son réseau est totalement secure, alors que si une seule machine est compromise via un port ouvert, tout le reste du réseau est exposé.
Non, je m'inscrit en faux. Les machines éteintes ont les ports fermés
moi
Oh, un sujet de débat: on ne devrait pas compiler les softs sur un serveur destiné à la production.
Si, on peut compiler les softs sur une machine destinée à la production ...... de packages :)
Ha bon ? Il parait que des fous furieux se servent de FreeBSD comme serveur, et ces cons ils compilent leurs ports si besoin. Mais tu as raison, ça n'est certainement pas destiné à la production.
Des malades !!
Bah, une fois compillé le soft, tu peux toujours virer les sources hein, si ce n'est que ça .
oui, sous les BSD on fait make clean puis make distclean puis make clean-depends
Nettoyé
Oh, un sujet de débat: on ne devrait pas compiler les softs sur un
serveur destiné à la production.
Si, on peut compiler les softs sur une machine destinée à la production
...... de packages :)
Ha bon ? Il parait que des fous furieux se servent de FreeBSD comme
serveur, et ces cons ils compilent leurs ports si besoin. Mais tu as
raison, ça n'est certainement pas destiné à la production.
Des malades !!
Bah, une fois compillé le soft, tu peux toujours virer les sources
hein, si ce n'est que ça .
oui, sous les BSD on fait make clean puis make distclean
puis make clean-depends
Oh, un sujet de débat: on ne devrait pas compiler les softs sur un serveur destiné à la production.
Si, on peut compiler les softs sur une machine destinée à la production ...... de packages :)
Ha bon ? Il parait que des fous furieux se servent de FreeBSD comme serveur, et ces cons ils compilent leurs ports si besoin. Mais tu as raison, ça n'est certainement pas destiné à la production.
Des malades !!
Bah, une fois compillé le soft, tu peux toujours virer les sources hein, si ce n'est que ça .
oui, sous les BSD on fait make clean puis make distclean puis make clean-depends
Nettoyé
moi
quelle légende ? il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et qu'ils maquillent l'identifiant en NTxxxx !
ce n'est pas la même légende !!!! la mienne parle de FreeBSD
et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code BSD, quasiment toute la pile TCP/IP, par exemple. ça fait 20 ans que Micro$oft court après Unix, sans le rattraper bien sûr. les légendes, elles sont à Redmond.
Exemple appliqué au ftp.exe de Doze
/cygdrive/c/WINDOWS $ cd system32
/cygdrive/c/WINDOWS/system32 $ strings ftp.exe | grep Regents @(#) Copyright (c) 1983 The Regents of the University of California.
Whouaou !!! la license est respectéee
Suite sur le ftp.exe de Cygwin :
/usr/bin $ strings ftp.exe | grep Regents
lamentable.
c'est pourtant le même client
cygwin a violé la license Berkeley
on doit donc fusiller cygwin
quelle légende ?
il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et
qu'ils maquillent l'identifiant en NTxxxx !
ce n'est pas la même légende !!!!
la mienne parle de FreeBSD
et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code
BSD, quasiment toute la pile TCP/IP, par exemple.
ça fait 20 ans que Micro$oft court après Unix, sans le rattraper bien sûr.
les légendes, elles sont à Redmond.
Exemple appliqué au ftp.exe de Doze
THIERRY@CLEMENT /cygdrive/c/WINDOWS
$ cd system32
THIERRY@CLEMENT /cygdrive/c/WINDOWS/system32
$ strings ftp.exe | grep Regents
@(#) Copyright (c) 1983 The Regents of the University of California.
quelle légende ? il est ultra connu que les serveurs de Micro$oft tournent sous OpenBSD et qu'ils maquillent l'identifiant en NTxxxx !
ce n'est pas la même légende !!!! la mienne parle de FreeBSD
et si Win$ 2000 et XP ont progressé, c'est parce qu'ils sont bourrés de code BSD, quasiment toute la pile TCP/IP, par exemple. ça fait 20 ans que Micro$oft court après Unix, sans le rattraper bien sûr. les légendes, elles sont à Redmond.
Exemple appliqué au ftp.exe de Doze
/cygdrive/c/WINDOWS $ cd system32
/cygdrive/c/WINDOWS/system32 $ strings ftp.exe | grep Regents @(#) Copyright (c) 1983 The Regents of the University of California.
Whouaou !!! la license est respectéee
Suite sur le ftp.exe de Cygwin :
/usr/bin $ strings ftp.exe | grep Regents
lamentable.
c'est pourtant le même client
cygwin a violé la license Berkeley
on doit donc fusiller cygwin
Gilles-Claude Rajaobelina
quelle légende ? [...] les légendes, elles sont à Redmond.
Exemple appliqué au ftp.exe de Doze
/cygdrive/c/WINDOWS $ cd system32
/cygdrive/c/WINDOWS/system32 $ strings ftp.exe | grep Regents @(#) Copyright (c) 1983 The Regents of the University of California.
Whouaou !!! la license est respectéee
Suite sur le ftp.exe de Cygwin :
/usr/bin $ strings ftp.exe | grep Regents
lamentable.
c'est pourtant le même client
cygwin a violé la license Berkeley
on doit donc fusiller cygwin
Bof. Dans ftp.c:
/* * Copyright (c) 1985, 1989, 1993, 1994 * The Regents of the University of California. All rights reserved. * [...] #ifndef lint static char sccsid[] = "@(#)ftp.c 8.6 (Berkeley) 10/27/94"; #endif /* not lint */
/*
* Copyright (c) 1985, 1989, 1993, 1994
* The Regents of the University of California. All rights reserved.
*
[...]
#ifndef lint
static char sccsid[] = "@(#)ftp.c 8.6 (Berkeley) 10/27/94";
#endif /* not lint */
quelle légende ? [...] les légendes, elles sont à Redmond.
Exemple appliqué au ftp.exe de Doze
/cygdrive/c/WINDOWS $ cd system32
/cygdrive/c/WINDOWS/system32 $ strings ftp.exe | grep Regents @(#) Copyright (c) 1983 The Regents of the University of California.
Whouaou !!! la license est respectéee
Suite sur le ftp.exe de Cygwin :
/usr/bin $ strings ftp.exe | grep Regents
lamentable.
c'est pourtant le même client
cygwin a violé la license Berkeley
on doit donc fusiller cygwin
Bof. Dans ftp.c:
/* * Copyright (c) 1985, 1989, 1993, 1994 * The Regents of the University of California. All rights reserved. * [...] #ifndef lint static char sccsid[] = "@(#)ftp.c 8.6 (Berkeley) 10/27/94"; #endif /* not lint */
Le Wed, 20 Dec 2006 23:46:30 +0000, nicolas vigier a écrit :
Et pourquoi faudrait il obligatoirement les fabriquer sur une autre machine ? Quel est l'interet de s'interdire l'utilisation d'un compilateur sur cette machine ?
Règle de sécurité N°1 : ne rien avoir qui ne soit nécessaire. Tous les ports fermés, sauf ceux liés aux services fournis. Tous les processus non liés au service fourni arrêté. Toutes les applis non liées aux services fournies désinstallées. Tu minimises ainsi les failles de sécurité et les risques de panne.
Oui, c'est legerement plus secure. Mais cela vaut il vraiment le cout par rapport aux inconvenients que ca apporte ?
Pour moi, avoir gcc installé sur la machine n'augmente pas de facon significative les risques.
-- http://n0x.org/ -
On 2006-12-21, Emmanuel Florac <eflorac@imaginet.fr> wrote:
Le Wed, 20 Dec 2006 23:46:30 +0000, nicolas vigier a écrit :
Et pourquoi faudrait il obligatoirement les fabriquer sur une autre
machine ? Quel est l'interet de s'interdire l'utilisation d'un compilateur
sur cette machine ?
Règle de sécurité N°1 : ne rien avoir qui ne soit nécessaire. Tous
les ports fermés, sauf ceux liés aux services fournis. Tous les
processus non liés au service fourni arrêté. Toutes les applis non
liées aux services fournies désinstallées. Tu minimises ainsi les
failles de sécurité et les risques de panne.
Oui, c'est legerement plus secure. Mais cela vaut il vraiment le cout
par rapport aux inconvenients que ca apporte ?
Pour moi, avoir gcc installé sur la machine n'augmente pas de facon
significative les risques.
Le Wed, 20 Dec 2006 23:46:30 +0000, nicolas vigier a écrit :
Et pourquoi faudrait il obligatoirement les fabriquer sur une autre machine ? Quel est l'interet de s'interdire l'utilisation d'un compilateur sur cette machine ?
Règle de sécurité N°1 : ne rien avoir qui ne soit nécessaire. Tous les ports fermés, sauf ceux liés aux services fournis. Tous les processus non liés au service fourni arrêté. Toutes les applis non liées aux services fournies désinstallées. Tu minimises ainsi les failles de sécurité et les risques de panne.
Oui, c'est legerement plus secure. Mais cela vaut il vraiment le cout par rapport aux inconvenients que ca apporte ?
Pour moi, avoir gcc installé sur la machine n'augmente pas de facon significative les risques.
-- http://n0x.org/ -
Emmanuel Florac
Le Thu, 21 Dec 2006 22:51:26 +0000, nicolas vigier a écrit :
Oui, c'est legerement plus secure. Mais cela vaut il vraiment le cout par rapport aux inconvenients que ca apporte ?
Oh oui. En cas de problème, tu n'as pas à t'interroger sur les services qui ne sont pas là...
Pour moi, avoir gcc installé sur la machine n'augmente pas de facon significative les risques.
Au contraire, c'est le plus dangereux, à n'installer sous aucun prétexte sur aucun serveur de production. Autant préinstaller un rootkit...
-- Sutor ne ultra Crepidam.
Le Thu, 21 Dec 2006 22:51:26 +0000, nicolas vigier a écrit :
Oui, c'est legerement plus secure. Mais cela vaut il vraiment le cout
par rapport aux inconvenients que ca apporte ?
Oh oui. En cas de problème, tu n'as pas à t'interroger sur les services
qui ne sont pas là...
Pour moi, avoir gcc installé sur la machine n'augmente pas de facon
significative les risques.
Au contraire, c'est le plus dangereux, à n'installer sous aucun prétexte
sur aucun serveur de production. Autant préinstaller un rootkit...
