Re: RES: Clone de micro = ghots
Já fiz instalações em massa com o partimage, fai e replicator e respondo a seis mensagens por mês nesta lista sobre este assunto. Vou tentar resumir minhas impressões (não vou comentar o dd pois imagino que queira fazer a instalação pela rede): a) partimage: cópia fiel do disco via rede. Rápido e pouco flexível (embora seja possível redimensionar as partições). Não é totalmente automatizado. Gasta muito espaço em disco dependendo da imagem (se compactar a imagem, fica bem mais lento). Se modificar a instalação padrão e quiser repetir em mais uma outra máquina, terá que recriar a imagem. b) fai: rápido se tiver um mirror interno, trabalhoso e extremamente flexível. Pode-se criar classes para instalar computadores diferentes e seleção de pacotes diferentes. Um pé no saco se tiver que instalar programas que não estão no Debian (drivers proprietários, softwares comerciais, etc..). Só vale a pena se for instalar em grandes quantidades iguais ou com grupos de trabalho bem definidos (levei uma semana para acertar uma instalação). Não precisa de um micro padrão já instalado, mas ajuda bastante para copiar o debconf, etc. É extremamente recomendável que se conheça bem como o sistema de empacotamento funciona, já que só instala os .deb facilmente (os outros tem que ser na mão). Usa o apt-get ou aptitude c) replicator: rápido e o mais fácil de configurar. Não é tão flexível quanto o fai mas o investimento inicial é bem menor. Faz a imagem de um micro já instalado e que é recomendado que não seja modificado. É recomendável o conhecimento de programação em bash ou perl, etc.. para criar scripts de configuração. Usa o rsync. No seu caso, sem dúvida partiria para o replicator... On Tue, 25 Oct 2005, Marlos.Sedrez wrote: Cara... Procura alguma documentacao do comando ~ dd ~ acho que ela vai servir como uma luva para vc ! http://www.oreillynet.com/linux/cmd/cmd.csp?path=d/dd Marlos Sedrez Atendimento em Banco de Dados Oracle/SQL Server/MSDE Linux User: 400480 Senior T.I. (47) 221-3300 ra - 513. <[EMAIL PROTECTED]> -Mensagem original- De: Marcos Vinicius Lazarini [mailto:[EMAIL PROTECTED] Enviada em: segunda-feira, 24 de outubro de 2005 23:18 Para: Paulo Marcondes Cc: DUP Assunto: Re: Clone de micro = ghots Paulo Marcondes wrote: Em 21/10/05, Marcelo Castilho Manzano<[EMAIL PROTECTED]> escreveu: Estou com 6 micros completamente iguais e preciso fazer um clone deles pra gravar em cd e depois só colocar o cd no drive e deixar o resto por conta do micro.. Qual software devo utilizar pra fazer isso... Não precisa fazer clone vc pode fazer uma instalação automática usando o fai. O fai é um canhão pra esse problema. Tente também o partimage www.partimage.org p/ mais informações -- Marcos -- ___ _ .''`. | |_ _. _| _ |_) _ ._ ._ _. : :' : | | |(_|(_|(/_|_| | (/_| || |(_| `. `'` Linux User #50500`- Prof.Adjunto - Instituto de Física ---Debian- Universidade Federal Fluminense Alpha/i386
Re: RES: Clone de micro = ghots
On Tue, 2005-10-25 at 11:04 -0200, Thadeu Penna wrote: > Já fiz instalações em massa com o partimage, fai e replicator e respondo a > seis mensagens por mês nesta lista sobre este assunto. Vou tentar resumir > minhas impressões (não vou comentar o dd pois imagino que queira fazer a > instalação pela rede): Eh possivel usar o dd pela rede tanto com o netcat quanto com uma conexao criptografada. Nao descarte ele pois eh uma opcao muito simples e pode ser bem pratica. > c) replicator: rápido e o mais fácil de configurar. > Não é tão flexível quanto o fai mas o investimento inicial é bem menor. > Faz a imagem de um micro já instalado e que é recomendado que não seja > modificado. É recomendável o conhecimento de programação em bash ou perl, > etc.. para criar scripts de configuração. Usa o rsync. > > No seu caso, sem dúvida partiria para o replicator... Pois eh, mas o replicator faz uma copia em nivel de arquivos, enquanto o partimage, dd, etc, faz copia direto dos blocos do disco. Acho que para o caso de ficar restaurando a toda hora sem se preocupar com reconfigurar o sistema, uma copia em mais baixo nivel seria o ideal.. Para copias em nivel de arquivos, o Unison eh uma ferramenta muito interessante e que agora possui uma interface grafica que facilita bastante e evita erros.. -- [] JA Tavares -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: Clone de micro = ghots
On Tue, 25 Oct 2005, Datacom - Tavares wrote: On Tue, 2005-10-25 at 11:04 -0200, Thadeu Penna wrote: Já fiz instalações em massa com o partimage, fai e replicator e respondo a seis mensagens por mês nesta lista sobre este assunto. Vou tentar resumir minhas impressões (não vou comentar o dd pois imagino que queira fazer a instalação pela rede): Eh possivel usar o dd pela rede tanto com o netcat quanto com uma conexao criptografada. Nao descarte ele pois eh uma opcao muito simples e pode ser bem pratica. Já não ficou tão simples :) Já tem que usar o netcat... c) replicator: rápido e o mais fácil de configurar. Não é tão flexível quanto o fai mas o investimento inicial é bem menor. Faz a imagem de um micro já instalado e que é recomendado que não seja modificado. É recomendável o conhecimento de programação em bash ou perl, etc.. para criar scripts de configuração. Usa o rsync. No seu caso, sem dúvida partiria para o replicator... Pois eh, mas o replicator faz uma copia em nivel de arquivos, enquanto o partimage, dd, etc, faz copia direto dos blocos do disco. Acho que para o caso de ficar restaurando a toda hora sem se preocupar com reconfigurar o sistema, uma copia em mais baixo nivel seria o ideal.. Você não precisar reconfigurar nada: fica quase tudo por conta do discover, etc. Muito menos ainda se as máquinas são iguais, como é o caso. Fazendo cópias de arquivos, você tem maior flexibilidade na divisão das partições (comparado com o partimage). Você pode ter um esquema de particionamento na máquina a ser replicada que é diferente da máquina modelo. Para copias em nivel de arquivos, o Unison eh uma ferramenta muito interessante e que agora possui uma interface grafica que facilita bastante e evita erros.. Eu só coloquei que o replicator usa o rsync para comparação. O usuário instalador não precisa saber usar o rsync. Lembre-se que estamos procurando instaladores em massa e automatizados, logo uma interface gráfica não vai ajudar em nada - você não quer clicar em 30 Ok's, certo :) Você colocar o cd ou o floppy de instalação e volta com a máquina pronta (o fai não pergunta nada, o replicator pede a senha de root, nome da máquina e para confirmar o reparticionamento). Esqueci de outro detalhe: se a instalação não é muito grande (em número de pacotes), você pode usar o fai-cd (faz um partial mirror no cd e instala a partir dele). Outra vantagem do fai é que você coloca o nome dos pacotes, se preferir instalar o etch vai ter os pacotes do dia da instalação. []s -- ___ _ .''`. | |_ _. _| _ |_) _ ._ ._ _. : :' : | | |(_|(_|(/_|_| | (/_| || |(_| `. `'` Linux User #50500`- Prof.Adjunto - Instituto de Física ---Debian- Universidade Federal Fluminense Alpha/i386
Re: RES: Clone de micro = ghots
On Tue, 2005-10-25 at 12:10 -0200, Thadeu Penna wrote: > On Tue, 25 Oct 2005, Datacom - Tavares wrote: > > On Tue, 2005-10-25 at 11:04 -0200, Thadeu Penna wrote: > >> Já fiz instalações em massa com o partimage, fai e replicator e respondo a > >> seis mensagens por mês nesta lista sobre este assunto. Vou tentar resumir > >> minhas impressões (não vou comentar o dd pois imagino que queira fazer a > >> instalação pela rede): > > > > Eh possivel usar o dd pela rede tanto com o netcat quanto com uma > > conexao criptografada. Nao descarte ele pois eh uma opcao muito simples > > e pode ser bem pratica. > > Já não ficou tão simples :) Já tem que usar o netcat... Aqui tem os comandos e toda a explicacao.. http://www.inference.phy.cam.ac.uk/saw27/notes/backup-hard-disk-partitions.html .. e eh muito simples sim.. :) > >> c) replicator: rápido e o mais fácil de configurar. > >> Não é tão flexível quanto o fai mas o investimento inicial é bem menor. > >> Faz a imagem de um micro já instalado e que é recomendado que não seja > >> modificado. É recomendável o conhecimento de programação em bash ou perl, > >> etc.. para criar scripts de configuração. Usa o rsync. > >> > >> No seu caso, sem dúvida partiria para o replicator... > > > > Pois eh, mas o replicator faz uma copia em nivel de arquivos, enquanto o > > partimage, dd, etc, faz copia direto dos blocos do disco. > > > > Acho que para o caso de ficar restaurando a toda hora sem se preocupar > > com reconfigurar o sistema, uma copia em mais baixo nivel seria o > > ideal.. > > > > Você não precisar reconfigurar nada: fica quase tudo por conta do > discover, etc. Muito menos ainda se as máquinas são iguais, como é > o caso. > > Fazendo cópias de arquivos, você tem maior flexibilidade > na divisão das partições (comparado com o partimage). Você pode ter um > esquema de particionamento na máquina a ser replicada que é diferente da > máquina modelo. Dah muita margem a erros.. Eh o tipo de coisa que precisas testar algumas vezes antes de botar em pratica. Nao podes simplesmente mandar dar um rsync ou tar ou seja lah o que for direto na raiz.. E o /dev? E o /proc? Muita coisa deve ser levada em conta.. Com o replicator, como fica o boot? o rsync nao vai escrever ele? Como ficam as definicoes de particoes? Este tipo de coisa nao serah clonada? > > Para copias em nivel de arquivos, o Unison eh uma ferramenta muito > > interessante e que agora possui uma interface grafica que facilita > > bastante e evita erros.. > > > > Eu só coloquei que o replicator usa o rsync para comparação. O > usuário instalador não precisa saber usar o rsync. Lembre-se que estamos > procurando instaladores em massa e automatizados, logo uma interface > gráfica não vai ajudar em nada - você não quer clicar em 30 Ok's, certo > :) Você colocar o cd ou o floppy de instalação e volta com a máquina > pronta (o fai não pergunta nada, o replicator pede a senha de root, nome > da máquina e para confirmar o reparticionamento). > > Esqueci de outro detalhe: se a instalação não é muito grande (em número de > pacotes), você pode usar o fai-cd (faz um partial mirror no cd e instala a > partir dele). Outra vantagem do fai é que você coloca o nome dos pacotes, > se preferir instalar o etch vai ter os pacotes do dia da instalação. Tenho certeza de que o Unison nao eh a ferramenta correta, apenas o citei, jah que eh uma ferramenta de sincronismo muito util, two-way (ao contrario do rsync) e pouco conhecida. Para ti, por exemplo, otima para sincronizar diretorios entre sua maquina em casa e na faculdade. Mas tenho uma pergunta aqui.. Tem uma outra ferramenta amplamente utilizada chamada UDPCast.. Pq ninguem a mencionou? Nao tenho conhecimento sobre o UDPCast, mas fazer uma imagem com o dd e escreve-la utilizando o UDPCast pode ser uma saida.. E dump de filesystem? Pq ninguem costuma fazer isto? -- [] JA Tavares -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: Clone de micro = ghots
Datacom - Tavares escreveu: > > >>> >>>Pois eh, mas o replicator faz uma copia em nivel de arquivos, enquanto o >>>partimage, dd, etc, faz copia direto dos blocos do disco. >>> >>>Acho que para o caso de ficar restaurando a toda hora sem se preocupar >>>com reconfigurar o sistema, uma copia em mais baixo nivel seria o >>>ideal.. >>> >>Você não precisar reconfigurar nada: fica quase tudo por conta do >>discover, etc. Muito menos ainda se as máquinas são iguais, como é >>o caso. >> >>Fazendo cópias de arquivos, você tem maior flexibilidade >>na divisão das partições (comparado com o partimage). Você pode ter um >>esquema de particionamento na máquina a ser replicada que é diferente da >>máquina modelo. > > > Dah muita margem a erros.. Não dá... > Eh o tipo de coisa que precisas testar algumas vezes antes de botar em > pratica. > Nao podes simplesmente mandar dar um rsync ou tar ou seja lah o que for > direto na raiz.. E quem disse que o replicator é isto?? Se fosse, não seria um pacote e sim um comando... > E o /dev? E o /proc? Muita coisa deve ser levada em conta.. > você nunca usou o replicator, não é ? O replicator não é um rsync de uma partição para outra. Veja em replicator.sf.net. Não precisa testar: se uma máquina funciona, então a outra funciona também. O replicator não copia o /proc/, /dev, /var/spool/umontedecoisas, etc.. só o que é necessário. Como saber o que é necessário ? O programa está na versão 3 e foi testada por muiita gente, desde o potato.. > Com o replicator, como fica o boot? o rsync nao vai escrever ele? Como > ficam as definicoes de particoes? Este tipo de coisa nao serah clonada? > Se quiser clone o esquema de partições, se não quiser não clone. Isto é o que eu chamo de flexível. Ele vai copiar o /usr de um para outro, como vc mesmo disse, arquivo por arquivo. Se for diferente o esquema de partições, é só o fstab que será diferente. O boot não é clonado, copia-se o lilo.conf e roda o lilo na máquina clone, depois de copiados os arquivos. O que eu coloco no postinst do replicator é reconfigurar o ssh (para gerar as chaves diferentes da máquina padrão) e eventualmente o xserver-xfree86 pois temos teclados diferentes aqui (us e abnt2). Só... > > >>>Para copias em nivel de arquivos, o Unison eh uma ferramenta muito >>>interessante e que agora possui uma interface grafica que facilita >>>bastante e evita erros.. >>> >> >>Eu só coloquei que o replicator usa o rsync para comparação. O >>usuário instalador não precisa saber usar o rsync. Lembre-se que estamos >>procurando instaladores em massa e automatizados, logo uma interface >>gráfica não vai ajudar em nada - você não quer clicar em 30 Ok's, certo >>:) Você colocar o cd ou o floppy de instalação e volta com a máquina >>pronta (o fai não pergunta nada, o replicator pede a senha de root, nome >>da máquina e para confirmar o reparticionamento). >> >>Esqueci de outro detalhe: se a instalação não é muito grande (em número de >>pacotes), você pode usar o fai-cd (faz um partial mirror no cd e instala a >>partir dele). Outra vantagem do fai é que você coloca o nome dos pacotes, >>se preferir instalar o etch vai ter os pacotes do dia da instalação. > > > Tenho certeza de que o Unison nao eh a ferramenta correta, apenas o > citei, jah que eh uma ferramenta de sincronismo muito util, two-way (ao > contrario do rsync) e pouco conhecida. > Sim. Só que você não vai querer um two-way onde um máquina não foi instalada ainda, certo ?? -- ___ _ .''`. | |_ _. _| _ |_) _ ._ ._ _. : :' : | | |(_|(_|(/_|_| | (/_| || |(_| `. `'` Linux User #50500`- Prof.Adjunto - Instituto de Física ---Debian- Universidade Federal Fluminense Alpha/i386 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: Clone de micro = ghots
On Tue, 2005-10-25 at 17:23 -0200, Thadeu Penna wrote: > >>Fazendo cópias de arquivos, você tem maior flexibilidade > >>na divisão das partições (comparado com o partimage). Você pode ter um > >>esquema de particionamento na máquina a ser replicada que é diferente da > >>máquina modelo. > > > > Dah muita margem a erros.. > > Não dá... Explique porque não dá.. A flexibilidade de configuracão dá margem a erros na configuracão do clone. Dá chance ao usuário de errar. O usuário é humano. :) Se você quer ter uma cópia fiel, você não precisa de um programa flexível, você só precisa de algo que faca uma cópia fiel, concordas? Qual a vantagem de se ter um particionamento diferente na máquina replicada? Se você quer máquinas particionadas de forma diferente, sua matriz deve estar da forma que você deseja as cópias.. > > Eh o tipo de coisa que precisas testar algumas vezes antes de botar em > > pratica. > > Nao podes simplesmente mandar dar um rsync ou tar ou seja lah o que for > > direto na raiz.. > > E quem disse que o replicator é isto?? Se fosse, não seria um pacote e > sim um comando... Comandos? Exemplifique.. Até o dd faz parte de um pacote.. Não entendi.. > > E o /dev? E o /proc? Muita coisa deve ser levada em conta.. > > > você nunca usou o replicator, não é ? O replicator não é um rsync de uma > partição para outra. Veja em replicator.sf.net. Não precisa testar: se > uma máquina funciona, então a outra funciona também. O replicator não > copia o /proc/, /dev, /var/spool/umontedecoisas, etc.. só o que é > necessário. Como saber o que é necessário ? O programa está na versão 3 > e foi testada por muiita gente, desde o potato.. Não pois não vejo uma situacão onde ele seria útil e que eu não pudesse fazer de outras formas.. :) Mas o /dev é necessário e deve ser copiado :P Pois é, o tar, o dd, o cpio nem precisam ser testados por um monte de gente.. eles estão ai desde que você nasceu :) > > Com o replicator, como fica o boot? o rsync nao vai escrever ele? Como > > ficam as definicoes de particoes? Este tipo de coisa nao serah clonada? > > Se quiser clone o esquema de partições, se não quiser não clone. Isto é > o que eu chamo de flexível. Ele vai copiar o /usr de um para outro, como > vc mesmo disse, arquivo por arquivo. Se for diferente o esquema de > partições, é só o fstab que será diferente. Não, não é só o fstab, é a quantidade de blocos em cada particão, é o tamanho e localizacão delas, é a localizacão e fragmentacão dos arquivos, etc, etc, tudo está sendo colocado em locais diferentes.. Até mesmo o lilo ou outro boot manager não apontará para a localizacão correta do kernel. Ao fim da cópia não tens um clone fiel. Se não tens um clone fiel, não podes dar 100% de certeza que irá funcionar.. > O boot não é clonado, copia-se o lilo.conf e roda o lilo na máquina > clone, depois de copiados os arquivos. O que eu coloco no postinst do > replicator é reconfigurar o ssh (para gerar as chaves diferentes da > máquina padrão) e eventualmente o xserver-xfree86 pois temos teclados > diferentes aqui (us e abnt2). Só... Pois é, a parte do lilo é problema derivado da cópia em nível de arquivos. > >>>Para copias em nivel de arquivos, o Unison eh uma ferramenta muito > >>>interessante e que agora possui uma interface grafica que facilita > >>>bastante e evita erros.. > >>> > >> > >>Eu só coloquei que o replicator usa o rsync para comparação. O > >>usuário instalador não precisa saber usar o rsync. Lembre-se que estamos > >>procurando instaladores em massa e automatizados, logo uma interface > >>gráfica não vai ajudar em nada - você não quer clicar em 30 Ok's, certo > >>:) Você colocar o cd ou o floppy de instalação e volta com a máquina > >>pronta (o fai não pergunta nada, o replicator pede a senha de root, nome > >>da máquina e para confirmar o reparticionamento). > >> > >>Esqueci de outro detalhe: se a instalação não é muito grande (em número de > >>pacotes), você pode usar o fai-cd (faz um partial mirror no cd e instala a > >>partir dele). Outra vantagem do fai é que você coloca o nome dos pacotes, > >>se preferir instalar o etch vai ter os pacotes do dia da instalação. > > > > > > Tenho certeza de que o Unison nao eh a ferramenta correta, apenas o > > citei, jah que eh uma ferramenta de sincronismo muito util, two-way (ao > > contrario do rsync) e pouco conhecida. > > > > Sim. Só que você não vai querer um two-way onde um máquina não foi > instalada ainda, certo ?? Como disse anterior, o propósito do Unison é outro, mas serve para sincronizar o computador da faculdade de um professor de física com o computador que este mesmo professor possui em casa.. :) Mas uma coisa que eu não havia pensado.. Com o Unison (grafico! inclusive) em uma máquina mestre/matriz, você pode instalar a partir de outra fonte o base e mais um sshd na máquina a ser clonada e fazer um pull de todo o filesystem da matriz para as máquinas a serem clonadas resultando exatamente no mesmo que o seu replic
Re: RES: Clone de micro = ghots
Vamos lá... Datacom - Tavares escreveu: > On Tue, 2005-10-25 at 17:23 -0200, Thadeu Penna wrote: > Fazendo cópias de arquivos, você tem maior flexibilidade na divisão das partições (comparado com o partimage). Você pode ter um esquema de particionamento na máquina a ser replicada que é diferente da máquina modelo. >>> >>>Dah muita margem a erros.. >> >>Não dá... > > Explique porque não dá.. > A flexibilidade de configuracão dá margem a erros na configuracão do > clone. Dá chance ao usuário de errar. O usuário é humano. :) Usuários erram menos no Windows ??? É bem menos flexível... O que acontece com o dd se o usuário trocar o if pelo of (uma única letra) ? > Qual a vantagem de se ter um particionamento diferente na máquina > replicada? Se você quer máquinas particionadas de forma diferente, sua > matriz deve estar da forma que você deseja as cópias.. Uma instalação linux universal em micros não universais (alguns tem windows, outros tem outra distribuição), etc... Existem tantas justificativas para partições diferentes quanto o número de usuários. > > > >>>Eh o tipo de coisa que precisas testar algumas vezes antes de botar em >>>pratica. >>>Nao podes simplesmente mandar dar um rsync ou tar ou seja lah o que for >>>direto na raiz.. >> >>E quem disse que o replicator é isto?? Se fosse, não seria um pacote e >>sim um comando... > > > Comandos? Exemplifique.. > Até o dd faz parte de um pacote.. Não entendi.. Exemplos Um comando : ls um pacote: coreutils com o comando ls, com a documentação, com arquivos de configuração, etc... > > > >>>E o /dev? E o /proc? Muita coisa deve ser levada em conta.. >>> >> >>você nunca usou o replicator, não é ? O replicator não é um rsync de uma >>partição para outra. Veja em replicator.sf.net. Não precisa testar: se >>uma máquina funciona, então a outra funciona também. O replicator não >>copia o /proc/, /dev, /var/spool/umontedecoisas, etc.. só o que é >>necessário. Como saber o que é necessário ? O programa está na versão 3 >>e foi testada por muiita gente, desde o potato.. > > > Não pois não vejo uma situacão onde ele seria útil e que eu não pudesse > fazer de outras formas.. :) > Mas o /dev é necessário e deve ser copiado :P > Nunca vi ninguém copiar o /dev/. Existem o udev, devfs, MAKEDEV, etc.. > Pois é, o tar, o dd, o cpio nem precisam ser testados por um monte de > gente.. eles estão ai desde que você nasceu :) > Eu tenho mais de 40. Mas se ler o changelog do coreutils e do tar, já sofreram várias atualizações ainda este ano... > > >>>Com o replicator, como fica o boot? o rsync nao vai escrever ele? Como >>>ficam as definicoes de particoes? Este tipo de coisa nao serah clonada? >> >>Se quiser clone o esquema de partições, se não quiser não clone. Isto é >>o que eu chamo de flexível. Ele vai copiar o /usr de um para outro, como >>vc mesmo disse, arquivo por arquivo. Se for diferente o esquema de >>partições, é só o fstab que será diferente. > > > Não, não é só o fstab, é a quantidade de blocos em cada particão, é o > tamanho e localizacão delas, é a localizacão e fragmentacão dos > arquivos, etc, etc, tudo está sendo colocado em locais diferentes.. Até > mesmo o lilo ou outro boot manager não apontará para a localizacão > correta do kernel. Ao fim da cópia não tens um clone fiel. Se não tens > um clone fiel, não podes dar 100% de certeza que irá funcionar.. > > Ah,, você não está falando de Linux, está falando de clonar Windows, não é? Pois não entendo nada sobre fragmentação e nem localização de arquivos. O kernel (vmlinuz) é um arquivo binário, como outro qualquer. Não precisa atualizar o lilo se mover o kernel de inode (desde que dentro da mesma partição). O local do arquivo (no mundo linux) não tem a menor importância... > Mas uma coisa que eu não havia pensado.. Com o Unison (grafico! > inclusive) em uma máquina mestre/matriz, você pode instalar a partir de > outra fonte o base e mais um sshd na máquina a ser clonada e fazer um > pull de todo o filesystem da matriz para as máquinas a serem clonadas > resultando exatamente no mesmo que o seu replicator faz.. :) Cópia em > nível de arquivos .. > SSH instalado onde ? Se for no HD, tem que particionar, configurar a rede e baixar o pacote. Não é isto que o replicator faz. Já que você não quer ler a documentação, aí vai o resumo: a) monta uma partição / via nfs do servidor b) formata o disco, cria partições,etc.. c) copia via rsync da máquina a ser copiada d) opcionalmente atualiza arquivos de configuração ou reconfigura pacotes em uma jaula chroot. Roda o lilo. e) reboota e pronto (com pouquíssimas intervenções) -- ___ _ .''`. | |_ _. _| _ |_) _ ._ ._ _. : :' : | | |(_|(_|(/_|_| | (/_| || |(_| `. `'` Linux User #50500`- Prof.Adjunto - Instituto de Física ---Debian- Universidade Federal Fluminense Alpha/i386 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscri
Re: RES: Clone de micro = ghots
On Wed, 2005-10-26 at 16:51 -0200, Thadeu Penna wrote: > > Explique porque não dá.. > > A flexibilidade de configuracão dá margem a erros na configuracão do > > clone. Dá chance ao usuário de errar. O usuário é humano. :) > > Usuários erram menos no Windows ??? É bem menos flexível... O que > acontece com o dd se o usuário trocar o if pelo of (uma única letra) ? Nao dah pra comparar.. Em um sistema que engana o usuario fazendo-o clicar em Iniciar para Desligar, tudo eh possivel.. Na verdade, usar windows eh muito dificil e ele mesmo forca os usuarios ao erro. if e of, eh soh prestar atencao no que se estah fazendo, o help e manuais deixam bem claro. O problema nem eh trocar um por outro e sim trocar os dispositivos em si hda, hdb .. no meio de testes voce pode se enganar e submeter o dispositivo errado, mas isso voce sempre estarah sujeito em qualquer estrategia. Anyway, depois de fazer um script voce nao precisará ficar digitando os comandos e a chance de erro se tornará praticamente nula. > > Qual a vantagem de se ter um particionamento diferente na máquina > > replicada? Se você quer máquinas particionadas de forma diferente, sua > > matriz deve estar da forma que você deseja as cópias.. > > Uma instalação linux universal em micros não universais (alguns tem > windows, outros tem outra distribuição), etc... Existem tantas > justificativas para partições diferentes quanto o número de usuários. A questao original da thread objetiva a geracao de imagens identicas pois todas as maquinas destino sao identicas. > >>>Eh o tipo de coisa que precisas testar algumas vezes antes de botar em > >>>pratica. > >>>Nao podes simplesmente mandar dar um rsync ou tar ou seja lah o que for > >>>direto na raiz.. > >> > >>E quem disse que o replicator é isto?? Se fosse, não seria um pacote e > >>sim um comando... > > > > > > Comandos? Exemplifique.. > > Até o dd faz parte de um pacote.. Não entendi.. > > Exemplos > Um comando : > ls > um pacote: > coreutils > com o comando ls, com a documentação, com arquivos de configuração, etc... Epa, ls eh um programa, um executavel, um binario.. e nao um comando.. Comandos sao builtin em outros binarios, por exemplo, os comandos builtin da bash ou de um busybox.. > > Não pois não vejo uma situacão onde ele seria útil e que eu não pudesse > > fazer de outras formas.. :) > > Mas o /dev é necessário e deve ser copiado :P > > > > Nunca vi ninguém copiar o /dev/. Existem o udev, devfs, MAKEDEV, etc.. Dependendo da config do kernel voce irá precisar dos arquivos correspondentes aos dispositivos previamente no FS. Por exemplo, a uns tempos atras era conhecido o problema de iniciares o linux e nao teres o /dev/console :) > > Pois é, o tar, o dd, o cpio nem precisam ser testados por um monte de > > gente.. eles estão ai desde que você nasceu :) > > > > Eu tenho mais de 40. Mas se ler o changelog do coreutils e do tar, já > sofreram várias atualizações ainda este ano... Tio.. :) Sim, estao sempre sendo corrigidos ou alterados para suportarem novas tecnologias.. Outro argumento: sao mais difundidos e isso resulta em menor chance de possuirem erros.. Mais gente usa, mais bug eh reportado e corrigido.. Simples, nao? > >>>Com o replicator, como fica o boot? o rsync nao vai escrever ele? Como > >>>ficam as definicoes de particoes? Este tipo de coisa nao serah clonada? > >> > >>Se quiser clone o esquema de partições, se não quiser não clone. Isto é > >>o que eu chamo de flexível. Ele vai copiar o /usr de um para outro, como > >>vc mesmo disse, arquivo por arquivo. Se for diferente o esquema de > >>partições, é só o fstab que será diferente. > > > > > > Não, não é só o fstab, é a quantidade de blocos em cada particão, é o > > tamanho e localizacão delas, é a localizacão e fragmentacão dos > > arquivos, etc, etc, tudo está sendo colocado em locais diferentes.. Até > > mesmo o lilo ou outro boot manager não apontará para a localizacão > > correta do kernel. Ao fim da cópia não tens um clone fiel. Se não tens > > um clone fiel, não podes dar 100% de certeza que irá funcionar.. > > > > > > Ah,, você não está falando de Linux, está falando de clonar Windows, não > é? Pois não entendo nada sobre fragmentação e nem localização de > arquivos. O kernel (vmlinuz) é um arquivo binário, como outro qualquer. > Não precisa atualizar o lilo se mover o kernel de inode (desde que > dentro da mesma partição). O local do arquivo (no mundo linux) não tem a > menor importância... CLARO QUE NAO! Praticamente qualquer FS eh fragmentado, uns mais outros menos.. Soh nao se fragmentam os implementados para nao se fragmentarem :) O local do arquivo tem importancia no desempenho. Algumas aplicacoes especificas, algumas maquinas dedicadas ou embarcadas possuem esse requisito. Já li sobre os filesystems do linux darem suporte a isso.. No ext2 existem parametros de configuracao para que ele tente colocar os arquivos de forma continua.. Isso eh configuravel.. > > Mas uma coisa que eu não havia pensad
Re: RES: Clone de micro = ghots
On Thu, 27 Oct 2005, Datacom - Tavares wrote: On Wed, 2005-10-26 at 16:51 -0200, Thadeu Penna wrote: Explique porque não dá.. A flexibilidade de configuracão dá margem a erros na configuracão do clone. Dá chance ao usuário de errar. O usuário é humano. :) Usuários erram menos no Windows ??? É bem menos flexível... O que acontece com o dd se o usuário trocar o if pelo of (uma única letra) ? if e of, eh soh prestar atencao no que se estah fazendo, o help e manuais deixam bem claro. O problema nem eh trocar um por outro e sim trocar os dispositivos em si hda, hdb .. no meio de testes voce pode se enganar e submeter o dispositivo errado, mas isso voce sempre estarah sujeito em qualquer estrategia. Concordo. Então esqueçamos que usuário erra, certo ? Quem colocou esta consideração foi você ;) Anyway, depois de fazer um script voce nao precisará ficar digitando os comandos e a chance de erro se tornará praticamente nula. Concordo inteiramente, por isto que o replicator é um conjunto de scripts. Qual a vantagem de se ter um particionamento diferente na máquina replicada? Se você quer máquinas particionadas de forma diferente, sua matriz deve estar da forma que você deseja as cópias.. Uma instalação linux universal em micros não universais (alguns tem windows, outros tem outra distribuição), etc... Existem tantas justificativas para partições diferentes quanto o número de usuários. A questao original da thread objetiva a geracao de imagens identicas pois todas as maquinas destino sao identicas. Por isto que eu sugeri o replicator e não o fai. com o comando ls, com a documentação, com arquivos de configuração, etc... Epa, ls eh um programa, um executavel, um binario.. e nao um comando.. Comandos sao builtin em outros binarios, por exemplo, os comandos builtin da bash ou de um busybox.. Epa, eu uso o ls na linha de programa ou linha de comando ? command n 1: an authoritative direction or instruction to do something portanto ls é um comando... procure por ls unix no google: http://www.scism.sbu.ac.uk/law/UnixStuff/ls.html The Unix list directory (ls) command. A primeira página toda se refere ao comando ls do unix... Na Wikipedia, o primeiro exemplo de um comando do Unix é ls Dependendo da config do kernel voce irá precisar dos arquivos correspondentes aos dispositivos previamente no FS. Por exemplo, a uns tempos atras era conhecido o problema de iniciares o linux e nao teres o /dev/console :) copiar o /dev/console não adiantaria neste caso. O device é criado e não copiado. Se eu copiar o /dev/sda de algum lugar não vai instalar uma placa SCSI no meu micro, e nem copiar /dev/video instala minha webcam... CLARO QUE NAO! Praticamente qualquer FS eh fragmentado, uns mais outros menos.. Soh nao se fragmentam os implementados para nao se fragmentarem :) O local do arquivo tem importancia no desempenho. Algumas aplicacoes especificas, algumas maquinas dedicadas ou embarcadas possuem esse requisito. Já li sobre os filesystems do linux darem suporte a isso.. No ext2 existem parametros de configuracao para que ele tente colocar os arquivos de forma continua.. Isso eh configuravel.. Só é ponto para a instalação dos arquivos. Se o disco é fragmentado e usa o dd, a fragmentação segue.. instalando por arquivos, a fragmentação não existe, pois é feita de maneira contínua. Como eu sou mais velho, eu ainda me lembro de situações onde os arquivos tinham posição definida nos disquetes: era um mecanismo básico de proteção contra cópias (o editor "carta certa" era assim). Usávamos o dd do DOS (era um utilitário do Norton Utilities :) Depois disto não me lembro de nenhum uso e se pudesse apagar a lembrança do Carta Certa, meu cerébro agradeceria pois é mais uma informação inútil. Essa eh a principal diferenca de alguem da fisica na computacao e de alguem com a bagagem e graduacao em ciencia da computacao.. Jah observei isso algumas vezes em outros locais e no "mundo real".. Não seja preconceituoso. Vejamos: ENIAC - balística(física) - Atanasoff Berry - primeiro computador eletrônico - Física de IOWA von Neumann - matemático e com grandes contribuições à Física - algoritmos, etc.. Bardeen, Schockley - físicos - transistor Arthur, Cho - MBE manipulação de átomos em camadas. Dennis Ritchie - Unix e C - bacharel em física McIlroy - pipes, filtros e vários comandos Unix - físico Nick Holonyak - físico - LEDs Einstein e outros - previsão e desenvolvimento dos lasers Stallman - físico - GNU CERN - físicos - WWW, servidores Web meios magnéticos - física - dados em quantidade labs da IBM - físicos Hopfield- físico - redes neurais computadores mais rápidos no Top 500 - laboratórios de pesquisa Hubberman, Barabazi - física - grafos, redes scale-free - robutez da Internet Bill Gates - não sabe nada de física. gostaria muito de ver mais contribuições para o mundo real do pessoal da "Ciência da Computação". É uma das minha críticas mais ferozes (veja o mater
Re: RES: Clone de micro = ghots
On Thu, 2005-10-27 at 16:05 -0200, Thadeu Penna wrote: > >> com o comando ls, com a documentação, com arquivos de configuração, etc... > > > > Epa, ls eh um programa, um executavel, um binario.. e nao um comando.. > > Comandos sao builtin em outros binarios, por exemplo, os comandos > > builtin da bash ou de um busybox.. > > Epa, eu uso o ls na linha de programa ou linha de comando ? > command >n 1: an authoritative direction or instruction to do something > > portanto ls é um comando... > procure por ls unix no google: > http://www.scism.sbu.ac.uk/law/UnixStuff/ls.html The Unix list directory > (ls) command. > A primeira página toda se refere ao comando ls do unix... > > Na Wikipedia, o primeiro exemplo de um comando do Unix é ls E nao deixa de estar errado.. :) > > Dependendo da config do kernel voce irá precisar dos arquivos > > correspondentes aos dispositivos previamente no FS. > > Por exemplo, a uns tempos atras era conhecido o problema de iniciares o > > linux e nao teres o /dev/console :) > > copiar o /dev/console não adiantaria neste caso. O device é criado e não > copiado. Se eu copiar o /dev/sda de algum lugar não vai instalar uma placa > SCSI no meu micro, e nem copiar /dev/video instala minha webcam... Nao eh isso que estou dizendo, estou dizendo que em alguns casos precisas dos arquivos no filesystem.. Isto depende de como o kernel estah configurado.. CONFIG_DEVFS_FS: This is support for devfs, a virtual file system (like /proc) which provides the file system interface to device drivers, normally found in /dev. Devfs does not depend on major and minor number allocations. Device drivers register entries in /dev which then appear automatically, which means that the system administrator does not have to create character and block special device files in the /dev directory using the mknod command (or MAKEDEV script) anymore. Ou tens isso configurado no kernel (experimental) ou entao precisas dos arquivos no filesystem.. > > Essa eh a principal diferenca de alguem da fisica na computacao e de > > alguem com a bagagem e graduacao em ciencia da computacao.. > > Jah observei isso algumas vezes em outros locais e no "mundo real".. > > > > Não seja preconceituoso. Vejamos: > ENIAC - balística(física) - > Atanasoff Berry - primeiro computador eletrônico - Física de IOWA > von Neumann - matemático e com grandes contribuições à Física - algoritmos, > etc.. > Bardeen, Schockley - físicos - transistor > Arthur, Cho - MBE manipulação de átomos em camadas. > Dennis Ritchie - Unix e C - bacharel em física > McIlroy - pipes, filtros e vários comandos Unix - físico > Nick Holonyak - físico - LEDs > Einstein e outros - previsão e desenvolvimento dos lasers > Stallman - físico - GNU > CERN - físicos - WWW, servidores Web > meios magnéticos - física - dados em quantidade > labs da IBM - físicos > Hopfield- físico - redes neurais > computadores mais rápidos no Top 500 - laboratórios de pesquisa > Hubberman, Barabazi - física - grafos, redes scale-free - robutez da Internet > Bill Gates - não sabe nada de física. Alguns dos dinossauros ai nao sao do tempo da computacao.. Na verdade sao fisicos que deixaram a fisica de lado, hehe.. Os locais que mencionaste soh fazem USO de sistemas computacionais.. Essa lista ai soh indica que alguns caras interessados em computacao perderam tempo com fisica.. :) > gostaria muito de ver mais contribuições para o mundo real do pessoal da > "Ciência da Computação". É uma das minha críticas mais ferozes (veja o > material do "Debian em universidades" que apresentei duas vezes no Dia-D). > Enquanto houver a falácia do "formamos para o mercado", vai continuar > dependendo dos físicos e engenheiros para desenvolver os métodos > computacionais. Apesar de apaixonante, isto é off-topic. Nao estou ai para ser off-topic.. Estah interessante! As contribuicoes do pessoal da ciencia da computacao eh todo o resto que nao mencionaste, eh tudo o que temos hj.. O que quero dizer eh que a visao eh outra, eh uma visao do fazer e botar em pratica do engenheiro/fisico sem pensar muito nas consequencias contra a visao de projetista e experimentador do cara de ciencia da computacao, que analisa todas as possibilidades muito bem antes de botar em pratica e as vezes ateh desiste de implementar quando descobre que nao eh uma solucao ideal ou quando descobre que o melhor seria realizar a tarefa de outra forma.. Bom, esta eh soh a minha visao.. :) Vou ler teu material e discutimos no decorrer.. Mas o "formamos para o mercado" existe em todas as areas e os cientistas nao gostam muito do mercado e da pressa pra se ter produtos.. Gostam eh de criar tecnologias inovadoras.. O termo "formamos para o mercado" eh mais presente em Analise de Sistemas/Sistemas de Informacao.. Sabe a diferenca das duas, nao? Estas diferencas e as peculiaridades dos cursos, muitas vezes, nao sao claras para o pessoal que estah do lado de fora.. -- [] JA Tavares -- To UNSUBSC
Re: RES: Clone de micro = ghots
Datacom - Tavares wrote: On Wed, 2005-10-26 at 16:51 -0200, Thadeu Penna wrote: Qual a vantagem de se ter um particionamento diferente na máquina replicada? Se você quer máquinas particionadas de forma diferente, sua matriz deve estar da forma que você deseja as cópias.. Uma instalação linux universal em micros não universais (alguns tem windows, outros tem outra distribuição), etc... Existem tantas justificativas para partições diferentes quanto o número de usuários. A questao original da thread objetiva a geracao de imagens identicas pois todas as maquinas destino sao identicas. Quantas vezes vc viu um usuário pedir uma coisa quando na verdade quer outra? A ultima aqui da lista foi um cara que queria ver um filme com legenda, e provavelmente vai fazer o re-encode dele pra conseguir isso... :-) Novas opcoes devem ser propostas sim, e fica a critério do usuário qual método escolher. Eu pessoalmente só usaria o dd se os HDs já estivessem na mesma máquina. Eh o tipo de coisa que precisas testar algumas vezes antes de botar em pratica. Nao podes simplesmente mandar dar um rsync ou tar ou seja lah o que for direto na raiz.. E quem disse que o replicator é isto?? Se fosse, não seria um pacote e sim um comando... Ele quis dizer que o replicator não é um pacote de um programa; são vários scripts que trabalham em conjunto pra minimizar ao máximo a necessidade de interação humana. Óbvio, depois q vc fizer um script com o tar e rsync que leva todos os problemas em conta, vc faz isso com um comando, mas meio que 'reinventou a roda' Com o replicator, como fica o boot? o rsync nao vai escrever ele? Como ficam as definicoes de particoes? Este tipo de coisa nao serah clonada? Se quiser clone o esquema de partições, se não quiser não clone. Isto é o que eu chamo de flexível. Ele vai copiar o /usr de um para outro, como vc mesmo disse, arquivo por arquivo. Se for diferente o esquema de partições, é só o fstab que será diferente. Não, não é só o fstab, é a quantidade de blocos em cada particão, é o tamanho e localizacão delas, é a localizacão e fragmentacão dos arquivos, etc, etc, tudo está sendo colocado em locais diferentes.. Até mesmo o lilo ou outro boot manager não apontará para a localizacão correta do kernel. Ao fim da cópia não tens um clone fiel. Se não tens um clone fiel, não podes dar 100% de certeza que irá funcionar.. Ah,, você não está falando de Linux, está falando de clonar Windows, não é? Pois não entendo nada sobre fragmentação e nem localização de arquivos. O kernel (vmlinuz) é um arquivo binário, como outro qualquer. Não precisa atualizar o lilo se mover o kernel de inode (desde que dentro da mesma partição). O local do arquivo (no mundo linux) não tem a menor importância... CLARO QUE NAO! Praticamente qualquer FS eh fragmentado, uns mais outros menos.. Soh nao se fragmentam os implementados para nao se fragmentarem :) O local do arquivo tem importancia no desempenho. Algumas aplicacoes especificas, algumas maquinas dedicadas ou embarcadas possuem esse requisito. Já li sobre os filesystems do linux darem suporte a isso.. filesystems do seculo passado. Hoje a unica garantia que voce tem é que um arquivo vai estar dentro da partição. Concordo quando diz que o local do arquivo faz diferença, mas se quiser que um arquvio fique por volta de uma região no HD, faça uma nova partição lá e grave seu arquivo lá dentro. No windows, há sim importância da disposição física dos arquivos no HD, já que o filesystem é tonto e faz uma besteira atras da outra; se a gente não toma cuidado, a fragmentação fica tamanha q nem o próprio defrag do win2k/xp funciona mais! No linux, faz tempo que esse problema foi resolvido e não temos mais que esquentar a cabeça com detalhes assim. No ext2 existem parametros de configuracao para que ele tente colocar os arquivos de forma continua.. Isso eh configuravel.. Meu amigo, qual filesystem decente não tenta fazer isso por default? Não vale FAT e NTFS... :-) E outra coisa, só usa ext2 hoje quem formatou a partição a ultima vez faz mais de 5 anos... Bom, talvez usuários de flashdrives, mas ai a aplicação não é mais em HD. Mas uma coisa que eu não havia pensado.. Com o Unison (grafico! inclusive) em uma máquina mestre/matriz, você pode instalar a partir de outra fonte o base e mais um sshd na máquina a ser clonada e fazer um pull de todo o filesystem da matriz para as máquinas a serem clonadas resultando exatamente no mesmo que o seu replicator faz.. :) Cópia em nível de arquivos .. SSH instalado onde ? Se for no HD, tem que particionar, configurar a rede e baixar o pacote. Não é isto que o replicator faz. Já que você não quer ler a documentação, aí vai o resumo: a) monta uma partição / via nfs do servidor b) formata o disco, cria partições,etc.. c) copia via rsync da máquina a ser copiada d) opcionalmente atualiza arquivos de configuração ou reconfigura pacotes em uma jaula chroot. Roda o lilo. e) reboota e pronto (com pouquí
Re: RES: Clone de micro = ghots
On Sat, 2005-10-29 at 08:57 -0200, Marcos Lazarini wrote: > Datacom - Tavares wrote: > > CLARO QUE NAO! Praticamente qualquer FS eh fragmentado, uns mais outros > > menos.. Soh nao se fragmentam os implementados para nao se > > fragmentarem :) > > O local do arquivo tem importancia no desempenho. Algumas aplicacoes > > especificas, algumas maquinas dedicadas ou embarcadas possuem esse > > requisito. Já li sobre os filesystems do linux darem suporte a isso.. > > filesystems do seculo passado. Hoje a unica garantia que voce tem é que > um arquivo vai estar dentro da partição. Concordo quando diz que o local > do arquivo faz diferença, mas se quiser que um arquvio fique por volta > de uma região no HD, faça uma nova partição lá e grave seu arquivo lá > dentro. > No windows, há sim importância da disposição física dos arquivos no HD, > já que o filesystem é tonto e faz uma besteira atras da outra; se a > gente não toma cuidado, a fragmentação fica tamanha q nem o próprio > defrag do win2k/xp funciona mais! > No linux, faz tempo que esse problema foi resolvido e não temos mais que > esquentar a cabeça com detalhes assim. Nao entendi o que voce quis dizer com filesystems do seculo passado.. A que estas te referenciando? O ext2/3 ainda possui na sua configuracao as opcoes de "Fragment size" e "Fragments per group" que servem para tuning de fragmentacao.. Ele ainda se fragmenta, e nao eh pouco :) O ext2/3 tende a escrever arquivos em sequencia no disco, a partir do inicio dele.. Nao sou um expert no assunto, mas acredito que tem como colocar um arquivo em um determinado local numa particao e seta-la como RO para que o arquivo nao saia mais de lah. Ou melhor, com o atributo "i" no arquivo (immutable), tu podes garantir que o arquivo ficarah quieto e intocado.. > > No ext2 existem parametros de configuracao para que ele tente colocar os > > arquivos de forma continua.. Isso eh configuravel.. > > Meu amigo, qual filesystem decente não tenta fazer isso por default? Não > vale FAT e NTFS... :-) > E outra coisa, só usa ext2 hoje quem formatou a partição a ultima vez > faz mais de 5 anos... Bom, talvez usuários de flashdrives, mas ai a > aplicação não é mais em HD. Veja bem, o linux mexe (realoca) nos arquivos previamente guardados no disco para que os novos fiquem de forma continua. Isso nao acontece no windows com FAT e NTFS.. O parametro pra tuning que citei acima eh o responsavel por isso, acho que nao tinhas entendido o que estava querendo dizer.. Bom, eu soh uso ext2 por algumas razoes: - Nao preciso me preocupar com journaling e as cacas que podem acontecer com o FS devido a eu ter, em algum espaco de tempo, um jornal diferente do estado do FS. - Minha maquina nao dah crash.. Raramente ocorre.. Nao preciso do jornal.. - Jornal eh otimo para recuperacoes rapidas sem ter que verificar o disco todo, nao eh o meu caso.. Quando isso acontece, prefiro esperar e nao me preocupar.. - Com jornal o desempenho cai.. Como nao preciso de jornal, posso ter mais desempenho.. :) - E o principal motivo: uso nobreak e o linux congela 1x a cada 3 meses numa maquina que fica up 24hs por dia e que eu executo todo tipo de coisa nela.. :) Nao preciso de journaling.. :) - Ah, posso usar write cache! Ganho mais em desempenho sem perigo de ter um jornal diferente do estado do FS caso haja um crash.. (write cache e jornal eh uma das coisas mais perigosas que existe!) :) - Ah, experimente usar jornal em um notebook que costumar hibernar (meu caso com meu notebook!).. Se tiveres um erro durante a hibernacao (raro!) o estado do jornal vai estar inconsistente se comparado ao estado do FS.. > Vc há de concordar que essa de sugerir o unison foi só pra aumentar o > 'flame'; pra que usar um programa canhão c/ interface gráfica pra > resolver um problema que voce mesmo resolveria usando uma linha do dd? Tem uma thread minha congelada aqui na lista sobre backup usando dd.. procure por ela.. Na verdade, eu criei toda uma estrategia para backup com o dd e simplesmente nao funcionou por causa de algum motivo mistico.. Tenho usado o Unison para algumas coisas e cheguei a conclusao de que a melhor estrategia de backup eh utiliza-lo.. Eh realmente resolvi partir para backup em nivel de arquivos.. Irei proceder com mais posts na outra thread nos proximos dias.. Na verdade, o Unison apesar de grafico, na sua primeira execucao tu configuras o que queres levar em conta, nas proximas execucoes ele farah tudo automatico e a janela irah somente funcionar para voce visualizar o que estah acontecendo.. Ainda podes usar o unison por linha de comando se quiseres.. Ele tem recursos do rsync e irah me permitir backups incrementais, merges em arquivos, etc, etc.. Digamos que ele eh muito simples, amigavel, e na verdade eh tao simples que ateh agora nao cometi nenhum erro ou obtive um comportamento que nao queria utilizando-o.. > > Alem da nossa diferenca de idade, em nossos argumentos vemos > > precisamente o quanto diferimos nos nossos pon
Re: RES: Clone de micro = ghots
Voltando... Datacom - Tavares wrote: On Sat, 2005-10-29 at 08:57 -0200, Marcos Lazarini wrote: Datacom - Tavares wrote: CLARO QUE NAO! Praticamente qualquer FS eh fragmentado, uns mais outros menos.. Soh nao se fragmentam os implementados para nao se fragmentarem :) O local do arquivo tem importancia no desempenho. Algumas aplicacoes especificas, algumas maquinas dedicadas ou embarcadas possuem esse requisito. Já li sobre os filesystems do linux darem suporte a isso.. filesystems do seculo passado. Hoje a unica garantia que voce tem é que um arquivo vai estar dentro da partição. Concordo quando diz que o local do arquivo faz diferença, mas se quiser que um arquvio fique por volta de uma região no HD, faça uma nova partição lá e grave seu arquivo lá dentro. No windows, há sim importância da disposição física dos arquivos no HD, já que o filesystem é tonto e faz uma besteira atras da outra; se a gente não toma cuidado, a fragmentação fica tamanha q nem o próprio defrag do win2k/xp funciona mais! No linux, faz tempo que esse problema foi resolvido e não temos mais que esquentar a cabeça com detalhes assim. Nao entendi o que voce quis dizer com filesystems do seculo passado.. A que estas te referenciando? 5 ou 6 anos atrás as opções de filesystens eram mínimas, se não eram apenas o ext2. Desde então, os sistemas evoluiram bastante e incorporaram vários recursos e capacidades extras. O ext2/3 ainda possui na sua configuracao as opcoes de "Fragment size" e "Fragments per group" que servem para tuning de fragmentacao.. Ele ainda se fragmenta, e nao eh pouco :) Voce pode ver isso de dois jeitos: ele te dá liberdade e permite você escolher, ou você tem que escolher porque ele não consegue resolver sozinho qual o melhor. Nesse caso, eu prefiro ter um problema a menos pra me preocupar... O ext2/3 tende a escrever arquivos em sequencia no disco, a partir do inicio dele.. Nao sou um expert no assunto, mas acredito que tem como colocar um arquivo em um determinado local numa particao e seta-la como RO para que o arquivo nao saia mais de lah. Se isso fosse importante e valesse a pena, poderiamos achar tutoriais de como fazer isso, até no guia foca. Acho que não é o caso. Ou melhor, com o atributo "i" no arquivo (immutable), tu podes garantir que o arquivo ficarah quieto e intocado.. Eu li sobre esse atributo 'i' mas acho que só os BSDs que implementam. No linux ficou pro futuro... se é que vai existir. No ext2 existem parametros de configuracao para que ele tente colocar os arquivos de forma continua.. Isso eh configuravel.. Meu amigo, qual filesystem decente não tenta fazer isso por default? Não vale FAT e NTFS... :-) E outra coisa, só usa ext2 hoje quem formatou a partição a ultima vez faz mais de 5 anos... Bom, talvez usuários de flashdrives, mas ai a aplicação não é mais em HD. Veja bem, o linux mexe (realoca) nos arquivos previamente guardados no disco para que os novos fiquem de forma continua. Isso nao acontece no windows com FAT e NTFS.. O parametro pra tuning que citei acima eh o responsavel por isso, acho que nao tinhas entendido o que estava querendo dizer.. Bom, isso eu não confirmo nem nego, mas é plausível. Só não sei o quanto isso iria afetar a performance do sistema, sem mencionar o risco de perder mais informação do que gostaria (se na hora que ele está abrindo espaco pra gravar algo e o processo não termina? Nessa hora vc tem dois arquivos pela metade e não apenas um) Bom, eu soh uso ext2 por algumas razoes: - Nao preciso me preocupar com journaling e as cacas que podem acontecer com o FS devido a eu ter, em algum espaco de tempo, um jornal diferente do estado do FS. - Minha maquina nao dah crash.. Raramente ocorre.. Nao preciso do jornal.. - Jornal eh otimo para recuperacoes rapidas sem ter que verificar o disco todo, nao eh o meu caso.. Quando isso acontece, prefiro esperar e nao me preocupar.. - Com jornal o desempenho cai.. Como nao preciso de jornal, posso ter mais desempenho.. :) - E o principal motivo: uso nobreak e o linux congela 1x a cada 3 meses numa maquina que fica up 24hs por dia e que eu executo todo tipo de coisa nela.. :) Nao preciso de journaling.. :) - Ah, posso usar write cache! Ganho mais em desempenho sem perigo de ter um jornal diferente do estado do FS caso haja um crash.. (write cache e jornal eh uma das coisas mais perigosas que existe!) :) Vc menciona várias vezes inconsistência do jornal com o FS. Nunca vi isso acontecer, com o write-cache off. Isso só acontece no caso do hibernate? Agora, depois de todas as reinstalações e os paus causados pelo rompimento do delicado equilibro em que o ext2 vive (que presenciei), não fico nem um pouco seguro guardando meus dados em partições ext2, por mais no-break e bateria que eu tivesse... Tipo /home em reiser, xfs, etc. o resto pode mandar qquer coisa, depois eu uso o rsync pra restaurar o backup ;-) - Ah, experimente usar jornal em um notebook que costumar
Re: RES: Clone de micro = ghots
On Sat, 2005-11-05 at 02:13 -0200, Marcos Vinicius Lazarini wrote: > > Veja bem, o linux mexe (realoca) nos arquivos previamente guardados no > > disco para que os novos fiquem de forma continua. Isso nao acontece no > > windows com FAT e NTFS.. O parametro pra tuning que citei acima eh o > > responsavel por isso, acho que nao tinhas entendido o que estava > > querendo dizer.. > > Bom, isso eu não confirmo nem nego, mas é plausível. Só não sei o quanto > isso iria afetar a performance do sistema, sem mencionar o risco de perder > mais informação do que gostaria (se na hora que ele está abrindo espaco pra > gravar algo e o processo não termina? Nessa hora vc tem dois arquivos pela > metade e não apenas um) A performance do sistema eh muito degradada a medida que o disco fica quase cheio. Se voce estah abrindo espaco para gravar algo e o processo nao termina voce tem as seguintes acoes: - move arquivo em lugar indevido para outro lugar. - escreve no disco novo arquivo. Quando voce move, voce copia e depois apagar.. Na primeira operacao voce nao tem a possibilidade de perder informacoes. > > Bom, eu soh uso ext2 por algumas razoes: > > - Nao preciso me preocupar com journaling e as cacas que podem acontecer > > com o FS devido a eu ter, em algum espaco de tempo, um jornal diferente > > do estado do FS. > > - Minha maquina nao dah crash.. Raramente ocorre.. Nao preciso do > > jornal.. > > - Jornal eh otimo para recuperacoes rapidas sem ter que verificar o > > disco todo, nao eh o meu caso.. Quando isso acontece, prefiro esperar e > > nao me preocupar.. > > - Com jornal o desempenho cai.. Como nao preciso de jornal, posso ter > > mais desempenho.. :) > > - E o principal motivo: uso nobreak e o linux congela 1x a cada 3 meses > > numa maquina que fica up 24hs por dia e que eu executo todo tipo de > > coisa nela.. :) > > Nao preciso de journaling.. :) > > - Ah, posso usar write cache! Ganho mais em desempenho sem perigo de ter > > um jornal diferente do estado do FS caso haja um crash.. (write cache e > > jornal eh uma das coisas mais perigosas que existe!) :) > > Vc menciona várias vezes inconsistência do jornal com o FS. Nunca vi isso > acontecer, com o write-cache off. Isso só acontece no caso do hibernate? Isso acontece no caso de usares write-cache on e teres um crash.. Isso acontece se modificares o FS e mandares a maquina hibernar antes de ela propagar as alteracoes para o jornal. > Agora, depois de todas as reinstalações e os paus causados pelo rompimento > do delicado equilibro em que o ext2 vive (que presenciei), não fico nem um > pouco seguro guardando meus dados em partições ext2, por mais no-break e > bateria que eu tivesse... > Tipo /home em reiser, xfs, etc. > o resto pode mandar qquer coisa, depois eu uso o rsync pra restaurar o > backup ;-) Jah recuperei varios FAT32 com o NDD e as chances de recuperacao sao maiores do que do ext2, realmente.. :) > > - Ah, experimente usar jornal em um notebook que costumar hibernar (meu > > caso com meu notebook!).. Se tiveres um erro durante a hibernacao > > (raro!) o estado do jornal vai estar inconsistente se comparado ao > > estado do FS.. > > Isso eu nao sei dizer, mas tenho um amigo que tem um laptop com > suspend-to-disk funcionando a um bom tempo e nunca reclamou de nada... haha, pois eh, usar linux em laptops eh um pouco delicado.. Existem 500 modos (tuning) para economizar energia, etc, etc.. Mas pra isso o cara deve querer usar o laptop como um laptop! A maioria se satisfaz usando um laptop como um desktop e subutiliza/ignora os recursos adicionais oferecidos :) -- [] JA Tavares -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: Clone de micro = ghots
Datacom - Tavares wrote: On Sat, 2005-11-05 at 02:13 -0200, Marcos Vinicius Lazarini wrote: Bom, eu soh uso ext2 por algumas razoes: - Nao preciso me preocupar com journaling e as cacas que podem acontecer com o FS devido a eu ter, em algum espaco de tempo, um jornal diferente do estado do FS. - Minha maquina nao dah crash.. Raramente ocorre.. Nao preciso do jornal.. - Jornal eh otimo para recuperacoes rapidas sem ter que verificar o disco todo, nao eh o meu caso.. Quando isso acontece, prefiro esperar e nao me preocupar.. - Com jornal o desempenho cai.. Como nao preciso de jornal, posso ter mais desempenho.. :) - E o principal motivo: uso nobreak e o linux congela 1x a cada 3 meses numa maquina que fica up 24hs por dia e que eu executo todo tipo de coisa nela.. :) Nao preciso de journaling.. :) - Ah, posso usar write cache! Ganho mais em desempenho sem perigo de ter um jornal diferente do estado do FS caso haja um crash.. (write cache e jornal eh uma das coisas mais perigosas que existe!) :) Vc menciona várias vezes inconsistência do jornal com o FS. Nunca vi isso acontecer, com o write-cache off. Isso só acontece no caso do hibernate? Isso acontece no caso de usares write-cache on e teres um crash.. Isso acontece se modificares o FS e mandares a maquina hibernar antes de ela propagar as alteracoes para o jornal. Um simples 'sync' antes de hibernar não resolveria esse problema? -- Marcos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RES: Clone de micro = ghots
On Mon, 2005-11-21 at 01:35 -0200, Marcos Vinicius Lazarini wrote: > > Isso acontece no caso de usares write-cache on e teres um crash.. > > Isso acontece se modificares o FS e mandares a maquina hibernar antes de > > ela propagar as alteracoes para o jornal. > > Um simples 'sync' antes de hibernar não resolveria esse problema? 1) sync 2) escreve no log que foi feito um sync 3) hibernate .. o jornal nao estah coerente neste caso! se trocares o 2) por alguma tarefa executada pelo cron e interrompida no meio de sua execucao pelo hibernate, o jornal tambem estarah incoerente.. quando mandas hibernar, nao ha problemas de ter processos em execucao, etc.. eles voltarao a executar posteriormente (obvio!), mesmo se a carga deles for pesada em processamento ou escrita/leitura do disco.. na verdade, o meu medo eh unico, ter um jornal diferente do estado do FS apos um crash e entao na recuperacao ele esculhembar com o FS de vez .. este eh o fato que me mantem longe de FS jornalados.. -- [] JA Tavares -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
