| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | | O mínimo que posso fazer é registar-me e agradecer. Penso que me vai fazer muito jeito. Obrigado! p3gasus.
|
| | | | Parabens pelo documento. O meu comentario visa _APENAS_ melhorar o pouco que ainda e' possivel o teu trabalho.
Embora esteja sempre presente o prompt a indicar que o utilizador e' "root", deveria haver uma indicacao:
"Para efectuar todas as seguintes operacoes, excepto quando houver indicacao em contrario, deve fazer login como root."
E' um preciosismo, mas julgando pelo publico alvo que pode abranger, nunca sera' demais.
Depois, um pouco mais abaixo, temos as linhas:
root@zooropa>groupadd mysql
root@zooropa>useradd -g mysql -s /bin/false
Rapidamente o proprio autor notara' a "gralha" (devia ter dormido mais um pouco). O segundo comando do useradd ficara':
root@zooropa>useradd -g mysql -s /bin/false mysql
Mais uma vez, parabens pelo bom trabalho, espero ter contribuido com algo positivo.
Cheers.
^S^ |
| | | | | | | | Eu fico deveras agradecido. Vai-me fazer muito jeito, pois ando a tentar instalar/configurar o mod_ssl. Obrigado, Mário!!
Cumprimentos
Artur Martins Minho Campus Party (30 Jun|03 Ago) -> Viana do Castelo |
| | | | Eu acho sempre que quem está disposto a partilhar o seu conhecimento com os outros é de louvar.
Assim, aqui ficam os meus parabens pela iniciativa. Continua o mundo agradece!
"Mata-te a estudar e serás um cadaver culto" |
| | | | Bom, a primeira coisa que me veio à cabeça qd li 'Bleeding Egde' foi, ora vamos lah ver como se instala correctamente o software bleeding edge do momento, like apache2, mod_perl2, mysql 4 etc etc.
Desilusão minha qd vejo apache 1.3.27 , mod_perl 1.27.
Não quero denegrir o trabalho do mario e muito menos retirar-lhe a importancia que tem, gostei mto do artigo, eh conciso e detalhado sem entrar no chato, mas de facto, é apenas uma critica ao titulo do artigo, que me deu a entender 'eh pa um howto para instalar o soft bleeding edge do momento' mas quando o li, 'ohhh'.
Bom, se conseguir arranjar oportunidade talvez faça um howto para instalação/configuração do the latest of the latest, incluindo a customização do apache2 para se obter uma enorme performance. Não levem a mal se ainda não foi feito, mas tempo é coisa que tenho escassa, e aliada com mulher :) uma combinação perigosa.....
Novamente, bom artigo mario.
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | | | IMHO, nem todos os módulos para o Apache 2 estão suficientemente maduros para um servidor de produção. Só isso.
Mário Gamito
my web shelter |
| | | | Correcto, nesse aspecto concordo, nomeadamente com mod_perl e afins. Mas o comentário não se dirige (como está bem explicito no inicio do mesmo) ao facto de nao ser esse software a ser retratado, mas si ao facto se associar (IMHO erradamente) o Bleeding edge com as versões que o teu howto descreve (e bem).
Não entremos em dissertações (como acontece em 99% das discussões do gildot) sobre as versões a usar, pois não foi essa a minha intenção.
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | Mas sera' que ninguem usa isto ?
:)
E' raro encontrar um bom manual, ja' que o que se encontra documentado e' o mod_jk, e o mod_jk2 possui bastantes diferencas.
//vd |
| | | | | | Eu pessoalmente (nota: opinião pessoal dai gosto que seja respeitada!) não gosto de java e muito menos jsp e afins.
Lembro-me de que quando andei a investigar essas soluções (ainda não havia apache2) encontrei na altura uns howto's muito porreiros, que neste momento não consigo encontrar para te dar os links.
a minha .sig já aceita euros:
just my 0.1€'s. |
| | | | Em q licença é disponilizado este pequeno E MUITO interessante HOWTO?
Provavelmente - só podem lêr aqui e em mais lado nenhum...
|
| | | | | | É pá, desculpa lá a resposta um bocado brusca, mas já no startux me chatearam a molécula por causa das licenças dos textos que escrevo, como se isso fosse a coisa mais importante dos textos.
É assim: eu escrevo estes textos por gozo. Quem lhes achar alguma utilidade que os use, quem não achar que não os use. Faço-os na boa sem pensar em Copyrights, Copylefts, Copyups ou Copydowns.
Mas já que inisistem tanto na história das licenças (como se isso servisse de alguma coisa para textos de cá-ca-rá-cá-cá como estes), aqui vai (e vou tratar de assim que tiver algum tempinho lá escarrapachar a licença que tanta falta faz): Só podem consultar os textos no site e fazer uma cópia em impressora não profissional para leitura. Mais nada. Não têm licença para fazer absolutamente mais nada com os documentos que escrevo no startux.org. O Copyright e a propriedade intelectual dos documentos são unicamente minhas.
Mário Gamito
my web shelter |
| | | | Para quem faz os textos por gozo, a licença é um bocado restrictiva, ou não?
Só falta obrigares o pessoal a assinar um NDA e começares a processar quem falar sobre os teus textos... :)
BTW, tenho de concordar com o brandon, no que diz respeito à parte do "bleeding edge". Bleeding edge seria o Apache 2.
Bem sei que o Apache 2 ainda está verde (embora os gajos da Apache Found. já tenham dito que a partir da versão 2.0.45 este já pode ser considerado estável), mas o objectivo do "bleeding edge" não é mesmo esse? Usar software que pode dar o berro? :)
Devemos dar uma força à transição para o Apache 2. Mais dia menos dia vai ser preciso... Para já, os servidores de produção devem correr o Apache 1.3, concordo com isso, mas para quem tem pequenos servidores web em casa, e gosta de brincar com estas coisas, instalem o Apache 2 e ganhem experiência com ele (se bem que não seja tão diferente do 1.3 como parece).
E sempre se vão esmagando uns bugs pelo caminho... :-)
Cumps,
João Ribeiro
--
sena@smux.net
http://sena.smux.net/
|
| | | | | Para já, os servidores de produção devem correr o Apache 1.3, concordo com isso, mas para quem tem pequenos servidores web em casa, e gosta de brincar com estas coisas, instalem o Apache 2 Por acaso foi exactamente isso que fiz em casa à cerca de 2 ou 3 semanas.
Infelizmente o disco desse computador berrou a semana passada o que não me deu tempo para grandes brincadeiras, mas ainda deu para fazer umas coisas com o mod_python.
No woman ever falls in love with a man unless she has a better opinion of him than he deserves. |
| | | | Boas
A directoria /home/www/mason tem de ter as permissões com as quais o servidor web corre.
root@zooropa> mkdir -p /home/www/mason
Fica com permissões de root e como tal o user www/nobody não tem permissão de criar a versão compilada dos componentes de perl.
Patch:
+chown nobody.nobody /home/www/mason
over and out
|
| | | | | | Obrigado pela correcção.
Eu escrevi o texto praticamente todo de memória.
Alguma coisa havia de falhar :-)
Mário Gamito
my web shelter |
| | | | Boas.
Está porreiro o how-to. Começa a ser um hábito, Mário. Parabéns. :-)
Btw, o "(Ignore as aspas)" está mesmo a pedi-las.. :-)
@726, Nbk
|
| | | | É de louvar este tipo de documentos pois são sempre muito úteis. No entanto, e não desfazendo o trabalho do Gamito, acho que este tipo de HOWTOs é em grande parte responsável para o FUD que circula normalmente que o Linux é muito complicado. Este tipo de HOWTOs aplica-se a quem quer/gosta/necessita de instalar as coisa usando a source. Acho que é muito importante referir no inicio deste tipo de documentos que as coisas não necessitam de ser assim, e que este tipo de instalação é o pior caso. Se o utilizador está a instalar servidores para um site que tens tantas caracteristicas especiais que os RPMs default não servem (ainda por cima para coisas tao banais como o apache e os mod perl e php, etc), então ele não é um utilizador basico/iniciante, e então este HOWTO de pouco o ajuda, porque ele já deve saber fazer isso tudo.
Parece-me que o publico alvo destes HOWTOs são os utilizadores de Linux com menos conhecimentos, e esta é, na minha opinião a pior maneira de os ensinar. Deve-se começar por ensinar a maneira mais fácil de fazer as coisas.
A maior parte das distribuições modernas já vem com isto quase tudo de base, e então um HOWTO para fazer o mesmo, baseado no RH9, por exemplo, seria uma coisa mais ou menos assim:
1 - Instalar os seguintes RPMs: httpd-2.0.40-21.i386.rpm php-4.2.2-17.i386.rpm php-ldap-4.2.2-17.i386.rpm php-mysql-4.2.2-17.i386.rpm php-pgsql-4.2.2-17.i386.rpm mod_perl-1.99_07-5.i386.rpm mod_ssl-2.0.40-21.i386.rpm mod_python-3.0.1-3.i386.rpm
2 - Seguir para o install dos tar.gz dos modulos perl extra, etc.
Acho que partir logo do principio que se deve usar os tar.gz para instalar as coisas é mau. Sim, eu sei que podemos optimizar melhor as coisas, etc bla bla, mas para 99% das pessoas isso é irelevante. As opções de compilação usadas nos RPMs são boas e funcionam suficientemente bem, com a vantagem, que o proximo upgrade a um dos packages, é só fazer um rpm -Fvh qualquercoisa-newversion.rpm. Imagina-te que tens que gerir uma quantidade larga de servidores, e instalas assim as coisas. Vais demorar um eternidade. Agora sai uma nova versão do PHP, e lá vais tu repetir o processo novamente ...
Quanto muito, vai-se buscar a src.rpm, altera-se o .spec para as opções que queremos e instala-se o RPM feito à medida, se as de por default não nos servirem.
Gamito, não leves a mal a crítica, mas acho isto bastante importante, e acho que estas "viciado" em fazer as coisas desta maneira e que ao transmitires o conhecimento aos outros, é naturar que os ensines como custumas fazer, mas talvez seja a altura de experimentares outras formas de instalação de software que não involva o comando "make".
|
| | | | | | "e acho que estas "viciado" em fazer as coisas desta maneira"
Viva,
Obrigado pelas tuas observações.
Antes de mais, já estou convertido aos RPMs há tempos :-), simplesmente neste caso, as opções de configuração e o número de bibliotecas envolvidas são tão retorcidas que me pareceu a compilação ser a melhor maneira de fazer as coisas.
Por outro lado, o facto de muitas vezes só existirem RPMs para Red Hat, também não ajuda. A Sablotron é um exemplo disso mesmo neste caso.
E sim, claro, o documento é dirigido a quem não sabe fazer as coisas, como digo no artigo.
Abraço,
P. S.: Eu só continuo a achar que mostrar aos n00bies que têm o código fonte para poder compilar é a melhor maneira de lhes transmitir *na prática* o conceito de open source. Caso contrário, ficam com a impressão de que os RPMs são uma espécie de .exe do Windows, o que não é verdade.
Mário Gamito
my web shelter |
| | | | | Só para dar um exemplo entre a diferença entre um rpm e um .gz compilado especificamente para a tua máquina, numa instalação de um PostgreSQL passei de um query de 24 segundos (RPM) para 8 segundos (.gz). Quando estás interessado em performance deixa lá isso dos RPM's e agradece lá à malta do OpenSource terem as sources para download :)
"Se vi mais além do que outro, é porque estava nos ombros de gigantes."
Sir Isaac Newton
|
| | | | | Quando estava a ler o teu comentário, lembrei-me imediatamente de outros que me tinham sido feitos há uns anos, quando lancei um "como compilar um xfree a partir das sources", aqui no gil. Fui ao gildot procurar, e o que é que encontro? O mesmo _mordor_ (ver #3), 2 anos mais novo, com o mesmo discurso! Realmente tenho que te dar os parabéns pela coerência... Mas apenas por isso! É que dizer que documentação contribui para FUD é o mesmo que dizer que um manual detalhado de uma televisão afasta os seus potenciais compradores. Repara, os documentos têm títulos, e têm um alvo específico: quem os quer ler, como é óbvio. Um documento que diga "como compilar X" é para quem quer compilar X, não serve para afastar quem não o quer fazer! Para esses existem as cheat-sheets. Como meteste no teu comentário, um "howto" simplista para este caso, usando rpm's, escreve-se em três ou quatro linhas. Isso não serve para produzir um howto-- ninguém vai publicar um howto desses: vejam aqui neste site o meu brutal texto que explica como se instala apache -- 3 rpms... No entanto, vários casos simplistas podem ser reunidos numa cheat-sheet. Mas a existência de cheat-sheets não determina a extinção de howtos, ou documentos mais abrangentes, os quais são supostos ter alguns detalhes, ensinar como as coisas se interligam e funcionam. É para isso que servem!
|
| | | | Vou responder aos dois comentário acima.
PostgreSQL passei de um query de 24 segundos (RPM) para 8 segundos (.gz)
Optimo. Precisaste de optimizar o PostgreSQL, e pelos visto conseguiste. Agora, achas que o PostgreSQL em RPM, não tém performance suficiente para 99% das utilizações que lhe dão? Achas que é necessário compilar? Não me parece. Onde trabalho, temos DB suportadas em PostgreSQL, que fazem muitos milhares de transações por dia. As optimizações que fizemos foi ao nível do nosso código (estruturas das tabelas e querys), e o PostgreSQL anda bem. Também já experimentei compilar o PostgreSQL, mas não melhorou nada de significativo, por isso achei que não valia a pena para o meu caso... e acho que não vale a pena para a maioria das pessoas.
É que dizer que documentação contribui para FUD é o mesmo que dizer que um manual detalhado de uma televisão afasta os seus potenciais compradores.
Acho que não percebeste o que quis dizer. Apresentar um documento destes, como sendo um HOWTO para os utilizadores iniciantes, passa a ideia que esta é a única forma de fazer as coisas. Estou farto de ouvir comentários de certos utilizadores que me dizem que o Linux é muito complicado porque é preciso andar a compilar tudo. O que gostaria de ver nestes documentos, é um indicação da forma simples de instalar (rpm -Uvh blabla.rpm), e a seguir dizer: "se quer fazer o fine-tunning pode usar a source, e então faz-se assim...". O documento do Gamito chama-se com instalar Apache, PHP, etc.. e não como compilar. Espero que tenha explicado melhor o meu ponto de vista.
Mais importante ainda que estes documento de como instalar/compilar, acho que são os como utilizar, isto é, como configurar o Apache (por exemplo) para fazer isto ou aquilo. Desse tipo de documentos vejo muito pouco. Tenho em conta que hoje em dia as distribuições já instalam essas coisas todas, o dificil mesmo é tirar partido delas. Assim, um doc a mostrar como se faz um modulo em perl para fazer o uma página com o "Hello world" e integrar com o mod_perl, por exemplo, parece-me que seria muito mais útil e inovativo.
|
| | | | Para quem estiver interessado neste assunto, saiu 'a poucos dias no securityfocus um artigo do mesmo tipo a instalacao do Apache 1.3.x, para que tem fortes preocupacoes com a seguranca. Algo que podera' ajudar e complementar para muitos. o link e' este.
|
| |
|
