DISTRIBUIÇÕES - 1
Jorge Godoy wrote:
>
> On Mon, 8 Feb 1999, Bruno de Oliveira Ferrarese wrote:
>
> > O Slackware eh mais leve (nao falo em performance, mas
> > IMSHO tb) tem menos arquivos pra se configurar (vc vai
> > direto onde quer, nao precisa dar voltas e olhar (esse aqui
> > faz isso e chama aquele, que por sua vez faz aquilo e chama
> > outro..)
>
> Acho isso interessante. Ao invés de cirar diversas entradas no cron, uma
> para cada programas rodado a cada hora, por exemplo, eu os copio todos
> dentro de /etc/cron.hourly que o RH automaticamente os executa a cada
> hora. Isso não é frescura, é conforto e facilidade para gerenciar. Não
> quer mais rodar? chmod -x arquivo_dentro_do_etc_cron_hourly
Eh exatamente a isse tipo de coisa que me refero. Se vc
usa, e gosta, se sente bem com isso, acho otimo, pois o
trabalho do pessoal da RH esta valendo a pena, mas pra min
atrapalha. Imagine vc pegar a maquina sem conhecer e vc tem
q alterar uma entrada no cron, vc vai direto crontab -e e
pronto, no seu caso tem que ficar dando greps pra achar em
qual alrquivo esta a linha que chama o prog.
Alem do mais, em minha humilde opiniao, tu tirar um
programa do crom dando um chmod -x chega ser ate
anti-etico!!
> > Agora escrevendo esse email me dei conta de uma coisa, na
> > verdade o principal: SIMPLICIDADE. isso resume tudo.
>
> Exactly. simplicidade, conforto e facilidade de realizar tarefas simples e
> tarefas complicadas. Podes ir direto nos arquivos no RH, sem medo nenhum.
> As ferramentas existem para facilitar (e até aumentar a segurança, algumas
> vezes...) e não são de uso obrigatório.
AUMENTAR???????
> > obs.: usei RH por 3 anos antes de ser apresentado ao
> > maravilhoso mundo do Slackware rodando com um AfterStep em
> > cima!
>
> After ruliz :-)) hehehehe...
> Usei-o no Slack, uso-o no RH, vou usá-lo até....... :-)))
> MAS, isso é outra flamewar... :-)))
Hehhheheheheheh que bom, mais um!!
Bruno de Oliveira Ferrarese TCPWrapper@zaz.com.br
---------------
Oi, Jorge
Lah vamos nos de novo :)
Estou lembrando da SIG do Getulio Holtz e te convidando prum chimarrao, pra
que o papo continue amigavel como estah ;)
>Isso é feito facilmente no RH e no Slackware
>editando-se o /etc/hosts.deny e acrescentando-se a linha "ALL:ALL".
>Libere, depois, em qualquer distribuição, no /etc/hosts.allow os serviços
>carregados pelo inetd que você desejar.
>Esse é o _mínimo_ de segurança. É óbvio que muitas outras coisas são
>necessárias, mas em qualquer distribuição.
Vc conhece o programa chkexploit e a rootshell. Teste num sistema Debian e
num RH. O que disse no mail anterior, eh que Debian eh mais indicado pra
SERVER. Concordo com vc, a melhor distribuicao eh aquela que a gente
conhece a fundo, mas eu nao vi ainda um ISP grande pequeno ou medio rodando
em MonkeyLinux, por exemplo. Quanto ao hosts.deny, posso garantir a vc que
este eh metodo bem ineficaz se vc se preocupa com seguranca.
>Isso começa antes da instalação. Começa no planejamento de como será feita
>a instalação.
Vc entendeu. Ele jah sabe o que quer e terah de se assessorar ou jah tem
algum know how em Unix para instalar seu server.
>Ainda é função do administrador de um sistema se manter atualizado... A
>distribuição vem desatualizada até pelo fato de ser um CD.
----SNIP----
Certo. Eu apenas disse que a interface do Debian, na minha opiniao e na de
dezenas de outros Sysadmins como eu, para upgrades atraves da Net eh muito
melhor. Um Sysadmin soh fica com sistema desatualizado, com Debian, se for
relaxado ou relapso.
>Exatamente. E ele pode fazer isto em qualquer distribuição. O RH é o mais
Vou usar mais uma vez o exemplo do Monkey...
>Eu preferiria parar no "tecer uma opinião sobre ele". Falar sobre o que
>não se conhece é cair em erro. O Guarani é bem diferente do RH nos
>pacotes. São mais atualizados e com várias correções feitas pelo pessoal
>da Conectiva e pelos autores dos pacotes.
Fico feliz em saber entao que no Brasil os responsaveis pelo RH sao mais
caprichosos e conscienciosos com seu produto. :)
Voce tem razao: jah agendei uma instalacao dele no meu K6 de testes pra nao
emitir opiniao sobre o que nao sei. Sobre o Marumbi eu sei bastante, mas
vamos deixar por aqui.
>Não vi nada de mais lá. Apenas uma comparação Debian/RH.
>No link que você indicou (http://www.ext2.org/99/02/imoore2.html) está um
>comentário interessante:
Interessante como eh facil omitir passagens que nao nos interessam e
ressaltar as que nos ajudam. Me parece que o assunto da materia eh o mesmo
do qual falamos, diferenca entre as distribuicoes. Uma sentenca que me
pareceu interessante e que vc (por motivos de espaco, obvio) esqueceu de
citar foi:
In comparison, RedHat is a company. They have to make money because they
have people they have to pay. So if a product is pushed back because it's
not ready, they loose money. This leads to hasty judgment calls and buggy
releases. RedHat is notorious for releasing buggy software. RedHat 4.2 was
one of the most stable and secure distributions I have ever used. But
version 4.0 and 4.1 were terrible. They were buggy and constantly had
security issues. The same thing happened with the release of 5.0 and 5.1. I
have heard good things about 5.2 though. With all of this said, it always
seems that it takes a few releases to get all the bugs worked out.
>Essa também é minha filosofia. Para mim, o Guarani foi excelente.
Pelos mesmos motivos defendo o Debian. Note que "In the Server Arena,
things run slightly different..."
>Vamos partir para o lado administrativo:
-----SNIPAO---------
Concordo plenamente, apenas nao estou entendendo o porque de comparar o
gerenciamento de versoes do Slack (inexistente) com o RPM. Por acaso nao
foi exatamente isso que eu disse no primeiro mail ao digitar: Com o Slack
vc precisarah reinstalar todo o sistema do zero a cada upgrade de Hardware
ou do Site?
>- (Só para ser chato, já que posso estar me metendo numa Flamewar, porque
> o pessoal da Debian cogitou em trocar o dpkg por rpm?? :-))) Veja na
> DebianWeek.
Vc eh um homem dos fatos, jah me disse em mails anteriores. O fato eh: isto
foi feito? A sugestao rolou nas listas Debian e Debian Devlopment - que eu
assino - porque o maior problema de aceitacao do Debian eh a interface
horrorosa do Dselect/Dpkg. Sabe qual foi a conclusao? Para resumir: Dane-se
a interface, queremos software bom. Tire suas conclusoes por sua conta,
apenas estou apresentando fatos. :)
>Vamos partir para o lado operacional:
>- Plug'n'Play.
>- Inovações tanto em Hardware quanto em Software
>- Apoio a projetos externos
Concordo plenamente com vc, mas nao estamos neste caso, falando de Servers
(vc escuta musica ou roda MP3 no seu server? Tem modem PNP nele? ) Quanto a
versoes e inovacoes de Soft, o KDE, p.ex. jah era parte integrante do DEB
muito antes de qualquer outra distribuicao. O AfterStep, tbm (coisa mais
antiquada, AfterStep, nao? - eh o que eu uso...). O Hylafax, tbm. O... Bom,
a lista toda vc pode ver numa lista do Dselect... :)
Para vc ter uma ideia, dezenas dos colaboradores do Debian sao os mesmos
que criaram os softwares que vc muito bem recompilou segundo suas
necessidades...
>Apoio comercial:
>- Em quem as grandes empresas estão investindo? (O seu
> gerente/diretor/chefe vai querer saber...)
Meu cliente (que em suma eh o meu patrao...) quer saber de um sistema
estavel, alheio a falhas, rapido e seguro. Na minha ignorancia, posso
garantir a este patrao que posso fazer isso com Debian, algo que jah nao
poderia fazer com RH - provavelmente por minha obtusidade. Mas se este
patrao (do qual dependem os sapatos e a escola de meu filho) quiser seguir
a moda, um bom argumento, o seu coracao ou fazer uma aposta, que posso
fazer? Apenas salvaguardar-me caso algum problema ocorra. Acho que a grande
questao a ser discutida nao eh qual deles eh o melhor e sim qual eh o mais
apropriado para determinada tarefa. E a minha opiniao, na Arena Server -
que eh onde tenho enfrentado meus leoes - o Debian eh a melhor Carabina a
minha disposicao - e nao me venha de estilingue, seu Jorge, q vc nao eh
David nem eu Golias! :^P
>
>Remember, you are a completely unique and distinct individual.
>Just like everyone else.
Rico Ferrari
Departamento de Tecnologia
suporte@ivixnet.com
-----------
Igor Sutton Lopes wrote:
> Concordo plenamente com isso mas, o que falta para o Slack seria o que o
> Stampede vai oferecer e o que o Debian, o SuSe e o RedHat possuem: um
> gerenciador de arquivos.
Estava resistindo a entrar nesta discussao, mas agora que li a palavra
magica (¨SuSE¨) nao resisti. Como varios outros companheiros da lista,
ja instalei e usei por algum tempo a maior parte das distribuicoes
¨mainstream¨. Conforme a gente avanca por este caminho, vai percebendo
que as diferencas entre as distribuicoes referem-se principalmente a
dois fatores basicos:
1) o ¨ponto de partida¨: o sistema basico que o administrador vai ter em
maos ao fim do processo de instalacao, e a partir do qual vai partir em
customizacoes, upgrades, updates, truques e tudo o mais que for
necessario para transformar a instalacao na sua ¨visao pessoal¨ do que
um sistema Linux deve ser. Naturalmente essa visao pessoal varia para
cada administrador, cada maquina e cada ocasiao, de acordo com varios
fatores, incluindo o servico desejado, o nivel de seguranca desejado, e
o conhecimento e talento pessoal do administrador.
2) os adicionais e diferenciais que cada distribuicao inclui e que as
outras deixam de incluir.
Neste sentido, o que pode levar a tantas respostas diferentes e´
principalmente este delta entre o que as distribuicoes oferecem e o que
o usuario deseja. Por exemplo, apos muito me bater com as ferramentas de
administracao de sistema oferecidas pelo slackware, red hat 4.2, redhat
5.x (linuxconf), turbo linux e suse (nesta ordem), acabei preferindo
estudar um pouco mais sobre o processo de boot e o padrao de organizacao
do filesystem do Linux para poder encontrar sozinho os arquivos de
configuracao e edita-los manualmente.
A maior parte dos adicionais oferecidos pelas diversas distribuicoes eh
de dominio publico, e portanto o administrador experiente pode
facilmente adicionar ao seu sistema (baseado na *sua* distribuicao
favorita) os pacotes adicionais oferecidos pelas distribuicoes
¨rivais¨.
Este palavrorio todo foi apenas para dar uma boa enrolada em voces antes
de eu tambem anunciar minha distribuicao favorita. Apos muitas voltas e
apos ter me fixado por um bom tempo no Turbo Linux 2.0, cheguei `a
conclusao que o SuSE e´ a distribuicao que mais se adapta `a minha visao
de sistema ideal. Isto porque:
1) Ele e´ baseado em rpm, facilitando o controle de pacotes instalados
2) A distribuicao basica sao 5 CDs, portanto ele apresenta *MUITA*
flexibilidade e amplitude de escolha de pacotes - claro que isto leva a
um processo de instalacao mais lento e sujeito a erros
3) As ferramentas de administracao fornecidas com ele sao solidas. O
Yast faz coisas que eu nunca tinha visto antes em programas de
administracao em dominio publico, o configurador de X praticamente
adivinha tudo sozinho, mas permite que voce altere o que quiser e teste
suas alteracoes dinamicamente, o configurador de impressoras faz
maravilhas, etc.
4) Os scripts de inicializacao sao originais, bem escritos e
documentados, e facilmente editaveis
5) O manual impresso pode ser comparado a muitos livros introdutorios
sobre *Linux*, ao contrario, por exemplo, do manual do Red Hat, que eh
apenas um guia de instalacao e configuracao da propria distribuicao.
Pronto, agora expus minha opiniao e tambem estou na discussao. Mas como
o nome deste sistema eh mesmo ¨grupo de discussao¨, acredito nao estar
cometendo nenhum pecado.
Augusto
brain@matrix.com.br
------------
Certo. Eu apenas disse que a interface do Debian, na minha opiniao e na de
>dezenas de outros Sysadmins como eu, para upgrades atraves da Net eh muito
>melhor. Um Sysadmin soh fica com sistema desatualizado, com Debian, se for
>relaxado ou relapso.
Sem querer aumentar a flame war, mas já aumentando :-)
Existem programas como:
AutoRPM,
rpmwatch,
rhlupdate
entre outros que fazem exatamente isso, atualizam via FTP.
Eu como Sysadmin (ou pelo menos tentando ser :-> ), acho essas ferramentas
viáveis apenas no intuito de ter os pacotes comigo.
mas para isso, prefiro fazer um mirror dos Updates (Red Hat, Conectiva) com
o programa de mirror do sunsite.
Mas não gosto de te-los atualizando sozinho. Eu prefiro atualizar na mão e
saber o que foi atualizado, o que mudou. Principalmente no que se refere a
configurações.
Esses dias fiz um upgrade do apache 1.2.x para 1.3.x
Só que ele vinha com o mod_SSL junto. O que aconteceu? Ele parou de
funcionar porque não tinha as bibliotecas instaladas (e por má construção
dele), ele não reclamou da falta das mesmas.
Antes que digam "viu só o problema do RPM/RedHat", esse pacote não era da
RedHat e o problema foi de construção do mesmo.
Mas de qualquer forma o ponto era que os arquivos de configurações não eram
mais compatíveis e por isso ele voltou para um default até que eu
atualizasse-o.
Imagine o que teria acontecido se ocorresse isso no meio da noite e só dia
seguinte (imagine um fim de semana) você descobrisse que o seu Servidor de
WEB esta parado por causa de uma atualização.
Por favor, senhores, essas são apenas as minhas impressões.
Quanto a flame war, ela não precisa ser uma flame war. Mas por favor, não
se acanhem de dizer algo por medo de transforma-la em uma.
Acho que essas discussões são as mais proveitosas da lista.
Raul Dias
------------
On Tue, 9 Feb 1999, Raul Dias wrote:
> >> AUMENTAR???????
>
> >Sim. Via lock, por exemplo. Impede duas pessoas de editarem o arquivo.
>
> E de que forma que o lock é implementado NO RED HAT?
> Serviço?
> Qual?
Depende. Pode-se implementar um sistema de travamento de arquivos
(file locking) de maneiras simples e maneiras mais complicadas (mas que
não deixam de ser simples :-)). As complicadas seriam as codificadas no
software. As simples podem ser implementadas nos scripts através da
checagem da existência de um arquivo. Por exemplo, toda vez que você
digitar um comando para editar algum arquivo --- esse comando é um
script, para te dar o exemplo --- ele pode verificar a existência do
arquivo /tmp/.nome_do_script.lock e, caso este exista, ele lhe informa que
"o arquivo está travado e/ou sendo alterado por outra pessoa, conforme o
pid contido no arquivo /tmp/.nome_do_script.lock". Se o arquivo de
travamento não existir, o mesmo é criado com o pid do script como seu
conteúdo e a alteração é permitida.
Essa é apenas uma das possibilidades. A criatividade mostra outras :-)
Não entendi as duas últimas perguntas... estão relacionadas ao lock ou ao
exemplo?
Sds,
Jorge Godoy
-----------
On Mon, 8 Feb 1999, Rico Ferrari wrote:
> Oi, Jorge
>
> Lah vamos nos de novo :)
> Estou lembrando da SIG do Getulio Holtz e te convidando prum chimarrao, pra
> que o papo continue amigavel como estah ;)
:-) Não sou fã de chimarrão, mas aceito o churrasco :-)))) (já me
convidei hehehehehehe)
> Vc conhece o programa chkexploit e a rootshell.
Conheço e uso.
> Teste num sistema Debian e
> num RH. O que disse no mail anterior, eh que Debian eh mais indicado pra
> SERVER.
Rico... Aqui está o "X". No meu sistema esses aplicativos não indicam
brechas. Uso RH. O Debian pode ser mais seguro sem nenhuma alteração, mas
duvido que você não mexa no seu Debian para melhorar a segurança após
instalado. Eu mexo nos RH que instalo.
> Concordo com vc, a melhor distribuicao eh aquela que a gente
> conhece a fundo, mas eu nao vi ainda um ISP grande pequeno ou medio rodando
> em MonkeyLinux, por exemplo. Quanto ao hosts.deny, posso garantir a vc que
> este eh metodo bem ineficaz se vc se preocupa com seguranca.
Repare no grifo feito em "_mínimo_". :-)
Esses arquivos são básicos para segurança. Há *sempre* uma necessidade de
se definir uma política de segurança e não apenas medidas de segurança. Só
a título de comentário (está fora do escopo desta discussão), o Monkey é
uma distribuição que roda em partições DOS (UMSDOS?) e portanto perde
algumas das vantagens do ext2. Ele não é recomendável para se rodar em
algo mais sério do que aprender Linux...
> >Isso começa antes da instalação. Começa no planejamento de como será feita
> >a instalação.
>
> Vc entendeu. Ele jah sabe o que quer e terah de se assessorar ou jah tem
> algum know how em Unix para instalar seu server.
Ou lê documentação que é válida para todas as distribuições, como os
famosos e ignorados HOWTOs.
> melhor. Um Sysadmin soh fica com sistema desatualizado, com Debian, se for
> relaxado ou relapso.
Não vou comentar pois já o fizeram... autorpm.... :-)
> >Não vi nada de mais lá. Apenas uma comparação Debian/RH.
> >No link que você indicou (http://www.ext2.org/99/02/imoore2.html) está um
> >comentário interessante:
> Interessante como eh facil omitir passagens que nao nos interessam e
> ressaltar as que nos ajudam. Me parece que o assunto da materia eh o mesmo
> do qual falamos, diferenca entre as distribuicoes. Uma sentenca que me
> pareceu interessante e que vc (por motivos de espaco, obvio) esqueceu de
> citar foi:
(Foi motivo de espaço mesmo. Estava preocupado com o limite da lista... e
por isso editei _muito_ este e-mail também...)
> security issues. The same thing happened with the release of 5.0 and 5.1. I
> have heard good things about 5.2 though. With all of this said, it always
> seems that it takes a few releases to get all the bugs worked out.
Já que é para fazer citações, viu a Slashdot hoje? :-)
Um poll e uma avaliação externa. A avaliação saiu na 32bitsonline e eu
ainda não consegui ler inteira... apenas "bati" o olho.
> >Essa também é minha filosofia. Para mim, o Guarani foi excelente.
> Pelos mesmos motivos defendo o Debian. Note que "In the Server Arena,
> things run slightly different..."
:-)
I know. We're all fighters.
> Concordo plenamente, apenas nao estou entendendo o porque de comparar o
> gerenciamento de versoes do Slack (inexistente) com o RPM. Por acaso nao
Comparei devido ao subject. Concordo --- e conheço muito bem! --- com o
que você disse.
> Vc eh um homem dos fatos, jah me disse em mails anteriores. O fato eh: isto
> foi feito? A sugestao rolou nas listas Debian e Debian Devlopment - que eu
> assino - porque o maior problema de aceitacao do Debian eh a interface
> horrorosa do Dselect/Dpkg. Sabe qual foi a conclusao? Para resumir: Dane-se
> a interface, queremos software bom. Tire suas conclusoes por sua conta,
> apenas estou apresentando fatos. :)
:-) Não consegui voltar ao link. Me parece que a decisão foi devido ao
fato de terem que refazer vários pacotes. Não estou afirmando! Não me
lembro exatamente do que li no artigo e qual foi a resposta... apenas
memorizei que eles cogitaram a troca de gerenciador.
> Concordo plenamente com vc, mas nao estamos neste caso, falando de Servers
> (vc escuta musica ou roda MP3 no seu server? Tem modem PNP nele? ) Quanto a
> versoes e inovacoes de Soft, o KDE, p.ex. jah era parte integrante do DEB
> muito antes de qualquer outra distribuicao. O AfterStep, tbm (coisa mais
> antiquada, AfterStep, nao? - eh o que eu uso...). O Hylafax, tbm. O... Bom,
> a lista toda vc pode ver numa lista do Dselect... :)
> Para vc ter uma ideia, dezenas dos colaboradores do Debian sao os mesmos
> que criaram os softwares que vc muito bem recompilou segundo suas
> necessidades...
Todos os aplicativos citados possuem versão em RPM.
Quanto aos argumentos para o PnP não acho válidos. Não é apenas placa de
som ou modem que é PnP. Placas de rede também o são e são as mais
facilmente encontradas no mercado. Se a qualidade destas placas é boa ou
não é outra coisa... O comentário sobre os desenvolvedores dos pacotes é
válido, novamente, para qualquer distribuição. Veja o fetchmail, por
exemplo. É o próprio Eric Raymond que mantém o RPM.
> Na minha ignorancia, posso garantir a este patrao que posso fazer isso
> com Debian, algo que jah nao poderia fazer com RH - provavelmente por
> minha obtusidade.
Não creio que sejas obtuso. Se o fosses, não estaríamos com a discussão
nessa mesma calma. Teria virado flame há muito tempo... :-) É aquela coisa
inexplicável que todo administrador tem: um modo de trabalho.
> apropriado para determinada tarefa. E a minha opiniao, na Arena Server -
> que eh onde tenho enfrentado meus leoes - o Debian eh a melhor Carabina a
> minha disposicao - e nao me venha de estilingue, seu Jorge, q vc nao eh
> David nem eu Golias! :^P
Hahahahahaha. Sim senhor, chefe! :-))
(Desculpe se editei demais... quase não passa pelo filtro de 8K).
Sds,
Jorge Godoy
-----------