From owner-svn-doc-all@freebsd.org Sun Sep 9 12:48:34 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4A96910943FC; Sun, 9 Sep 2018 12:48:34 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E813071FD2; Sun, 9 Sep 2018 12:48:33 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id D825919E8B; Sun, 9 Sep 2018 12:48:33 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w89CmXDd082827; Sun, 9 Sep 2018 12:48:33 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w89CmXND082821; Sun, 9 Sep 2018 12:48:33 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809091248.w89CmXND082821@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Sun, 9 Sep 2018 12:48:33 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52241 - in head/pt_BR.ISO8859-1/articles: . solid-state X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/articles: . solid-state X-SVN-Commit-Revision: 52241 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Sep 2018 12:48:34 -0000 Author: ebrandi Date: Sun Sep 9 12:48:32 2018 New Revision: 52241 URL: https://svnweb.freebsd.org/changeset/doc/52241 Log: pt_BR.ISO8859-1/articles/solid-state: New pt_BR translation into .po format * content synchronized with en_US document (rev 44923) * article.xml converted to .po * .po file was translated to pt_BR * .po and .xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/solid-state/ head/pt_BR.ISO8859-1/articles/solid-state/Makefile (contents, props changed) head/pt_BR.ISO8859-1/articles/solid-state/article.xml (contents, props changed) head/pt_BR.ISO8859-1/articles/solid-state/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/Makefile Modified: head/pt_BR.ISO8859-1/articles/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile Sat Sep 8 21:18:22 2018 (r52240) +++ head/pt_BR.ISO8859-1/articles/Makefile Sun Sep 9 12:48:32 2018 (r52241) @@ -25,6 +25,7 @@ SUBDIR+= port-mentor-guidelines SUBDIR+= pr-guidelines SUBDIR+= problem-reports SUBDIR+= remote-install +SUBDIR+= solid-state DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/solid-state/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/solid-state/Makefile Sun Sep 9 12:48:32 2018 (r52241) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: Solid State Devices + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/solid-state/article.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/solid-state/article.xml Sun Sep 9 12:48:32 2018 (r52241) @@ -0,0 +1,262 @@ + + + +
+ FreeBSD e Dispositivos de Estado Sólido + + + John Kozubik
+ john@kozubik.com +
+ + + 2001 2009 Projeto de Documentação do FreeBSD + + + FreeBSD is a registered trademark of the FreeBSD Foundation. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. + + + + + Copyright + + Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, HTML, PDF, PostScript, RTF and so forth) with or without modification, are permitted provided that the following conditions are met: + + + + Redistributions of source code (XML DocBook) must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified. + + + + Redistributions in compiled form (transformed to other DTDs, converted to PDF, PostScript, RTF and other formats) must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. + + + + + THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + + + + $FreeBSD$ + + $FreeBSD$ + + + Este artigo aborda o uso de dispositivos de disco de estado sólido no FreeBSD para criar sistemas embarcados. + + Os sistemas embarcados têm a vantagem de uma maior estabilidade devido à ausência de partes móveis (discos rígidos). No entanto, é preciso ter em conta que o espaço disponível em disco é geralmente baixo no sistema e a durabilidade do meio de armazenamento. + + Tópicos específicos a serem abordados incluem os tipos e atributos das mídia de estado sólido adequadas para uso como disco no FreeBSD, opções de kernel que são de interesse em tal ambiente, os mecanismos rc.initdiskless que automatizam a inicialização de tais sistemas e a necessidade de sistemas de arquivos read-only e a construção de sistemas de arquivos a partir do zero. O artigo será concluído com algumas estratégias gerais para ambientes FreeBSD pequenos e read-only . + + + + + Dispositivos de Disco de Estado Sólido + + O escopo deste artigo será limitado a dispositivos de disco de estado sólido feitos de memória flash. A memória flash é uma memória de estado sólido (sem partes móveis) que é não volátil (a memória mantém os dados mesmo depois de todas as fontes de energia terem sido desconectadas). A memória flash pode suportar um enorme choque físico e é razoavelmente rápida (as soluções de memória flash abordadas neste artigo são um pouco mais lentas que um disco rígido EIDE para operações de gravação e muito mais rápidas para operações de leitura). Um aspecto muito importante da memória flash, cujas ramificações serão discutidas mais adiante neste artigo, é que cada setor tem uma capacidade limitada de reescrita. Você só pode gravar, apagar e gravar novamente em um setor de memória flash um certo número de vezes antes que o setor fique permanentemente inutilizável. Embora muitos produtos de memória flash mapeiam automaticamente os blocos defeituo sos, e embora alguns até distribuam operações de gravação uniformemente por toda a unidade, a verdade é que existe um limite para a quantidade de escrita que pode ser feita no dispositivo. Unidades competitivas possuem entre 1.000.000 e 10.000.000 gravações por setor em suas especificações. Este valor varia com à temperatura do ambiente. + + Especificamente, estaremos discutindo unidades compact-flash compatíveis com ATA, as quais são bastante populares como mídia de armazenamento para câmeras digitais. De particular interesse é o fato de que eles são fixados diretamente no barramento IDE e são compatíveis com o conjunto de comandos ATA. Portanto, com um adaptador muito simples e de baixo custo, esses dispositivos podem ser conectados diretamente a um barramento IDE em um computador. Uma vez implementado desta maneira, sistemas operacionais como o FreeBSD vêem o dispositivo como um disco rígido normal (embora pequeno). + + Outras soluções de disco de estado sólido existem, mas seu custo, obscuridade e relativa dificuldade de uso os colocam além do escopo deste artigo. + + + + Opções do Kernel + + Algumas opções do kernel são de interesse específico para aqueles que criam sistemas FreeBSD embarcados. + + Todos os sistemas embarcados FreeBSD que usam memória flash como disco para o sistema estarão interessados ​​em usar discos em memória e sistemas de arquivos em memória. Devido ao número limitado de gravações que podem ser feitas na memória flash, o disco e os sistemas de arquivos no disco provavelmente serão montados como read-only. Nesse ambiente, sistemas de arquivos tais como /tmp e /var são montados como sistemas de arquivos em memória para permitir que o sistema crie logs e atualize contadores e arquivos temporários. Os sistemas de arquivos em memória são um componente crítico para uma implementação bem-sucedida do FreeBSD em dispositivos de estado sólido. + + Você deve ter certeza de que as seguintes linhas existem no seu arquivo de configuração do kernel: + + options MFS # Memory Filesystem +options MD_ROOT # md device usable as a potential root device +pseudo-device md # memory disk + + + + O Subsistema <literal>rc</literal> e os Sistemas de Arquivos Read-Only + + A inicialização pós-boot de um sistema FreeBSD embarcado é controlada por /etc/rc.initdiskless. + + O /etc/rc.d/var monta o /var como um sistema de arquivos em memória, cria uma lista configurável de diretórios em /var com o comando mkdir1 e altera os modos em alguns desses diretórios. Na execução do /etc/rc.d/var, uma outra variável rc.conf entra em jogo – varsize. Uma partição /var é criada por /etc/rc.d/var baseado no valor desta variável em rc.conf: + + varsize=8192 + + Lembre-se de que esse valor é informado em setores, por padrão. + + O fato do /var ser um sistema de arquivos read-write é uma distinção importante, pois a partição / (e quaisquer outras partições que você possa ter em sua mídia flash) deve ser montada como read-only. Lembre-se que em detalhamos as limitações da memória flash - especificamente a capacidade de gravação limitada. A importância de não montar sistemas de arquivos em mídia flash em modo read-write, e a importância de não usar um arquivo de swap, não pode ser exagerado. Um arquivo de swap em um sistema ocupado pode inutilizar uma mídia flash em menos de um ano. Criação de log pesado ou criação e destruição de arquivos temporários podem fazer o mesmo. Portanto, além de remover a entrada swap do seu /etc/fstab, você também deve alterar o campo Options para cada sistema de arquivos para ro como segue: + + # Device Mountpoint FStype Options Dump Pass# +/dev/ad0s1a / ufs ro 1 1 + + Alguns aplicativos no sistema começarão a falhar imediatamente como resultado desta alteração. Por exemplo, o cron não será executado corretamente como resultado da falta de crontabs no /var criado pelo /etc/rc.d/var, o syslog e o dhcp também irão encontrar problemas como resultado do sistema de arquivos estar em modo read-only e dos itens ausentes no /var que o /etc/rc.d/var criou. Estes são apenas problemas temporários, embora sejam abordados, juntamente com soluções para a execução de outros pacotes de software comuns em . + + Uma coisa importante para lembrar é que um sistema de arquivos que foi montado como read-only com o /etc/fstab pode ser colocado em modo read-write a qualquer momento, executando o comando: + + # /sbin/mount -uw partition + + e pode ser alternado de volta para somente leitura com o comando: + + # /sbin/mount -ur partition + + + + Construindo um sistema de arquivos a partir do zero + + Como os cartões Compact Flash compatíveis com ATA são vistos pelo FreeBSD como discos rígidos IDE normais, você poderia teoricamente instalar o FreeBSD a partir da rede usando o os disquetes do kern e mfsroot ou de um CD. + + No entanto, mesmo uma pequena instalação do FreeBSD utilizando procedimentos normais de instalação pode produzir um sistema com tamanho maior que 200 megabytes. Como a maioria das pessoas usará dispositivos de memória flash menores (128 megabytes são considerados razoavelmente grandes - 32 ou até mesmo 16 megabytes são comuns), uma instalação usando mecanismos normais não será possível - simplesmente não há espaço em disco suficiente nem para as menores instalações convencionais. + + A maneira mais fácil de superar essa limitação de espaço é instalar o FreeBSD usando meios convencionais em um disco rígido normal. Após a conclusão da instalação, reduza o sistema operacional para um tamanho que caiba na mídia flash e compacte o sistema de arquivos inteiro com o tar. Os passos seguintes irão guiá-lo através do processo de preparação de uma parte da memória flash para o seu sistema de arquivos compactado com o tar. Lembre-se de que não estamos executando uma instalação normal, logo as operações como particionamento, criação dos labels, criação do sistema de arquivos, etc. precisam ser executadas manualmente. Além dos disquetes do kern e mfsroot, você também precisará usar o disquete do fixit. + + + + Particionando seu Dispositivo de Mídia Flash + + Após inicializar com os disquetes do kern e mfsroot, escolha custom no menu de instalação. No menu de instalação personalizada, escolha partition. No menu de partições, você deve apagar todas as partições existentes usando a tecla d. Depois de excluir todas as partições existentes, crie uma partição usando a tecla c e aceite o valor padrão para o tamanho da partição. Quando perguntado sobre o tipo da partição, certifique-se de que o valor esteja configurado para 165. Agora escreva esta tabela de partições no disco pressionando w (esta é uma opção oculta nesta tela). Se você estiver usando um cartão compact flash compatível com ATA, deverá escolher o FreeBSD Boot Manager. Agora pressione q para sair do menu de partições. Você verá novamente o menu do gerenciador de inicialização - repita a escolha feita anteriormente.

+ + + + Criando Sistemas de Arquivos em seu Dispositivo de Memória Flash + + Saia do menu de instalação personalizada e, no menu de instalação principal, escolha a opção fixit. Depois de entrar no ambiente do fixit, digite o seguinte comando: + + # disklabel -e /dev/ad0c + + Neste ponto, você terá entrado no editor vi sob os auspícios do comando disklabel. Em seguida, você precisa adicionar uma linha a: no final do arquivo. Esta linha a: deve ser semelhante a linha abaixo: + + a: 123456 0 4.2BSD 0 0 + + Onde 123456 é um número o qual é exatamente o mesmo que o número existente na entrada c: para o tamanho. Basicamente, você está duplicando a linha c: existente como uma linha a:, certifique-se de que o fstype seja 4.2BSD. Salve o arquivo e saia. + + # disklabel -B -r /dev/ad0c +# newfs /dev/ad0a + + + + Colocando seu Sistema de Arquivos na Mídia Flash + + Monte a mídia flash recém-preparada: + + # mount /dev/ad0a /flash + + Coloque esta máquina na rede para que possamos transferir nosso arquivo tar e extrai-lo em nosso sistema de arquivos de mídia flash. Um exemplo de como fazer isso é: + + # ifconfig xl0 192.168.0.10 netmask 255.255.255.0 +# route add default 192.168.0.1 + + Agora que a máquina está na rede, transfira seu arquivo tar. Você pode se deparar com um pequeno dilema neste ponto - se a sua memória flash tiver por exemplo 128 megabytes, e seu arquivo tar for maior que 64 megabytes, você não poderá ter o seu arquivo tar na mídia flash ao mesmo tempo em que realiza a descompressão - você ficará sem espaço. Uma solução para esse problema, se você estiver usando FTP, é descompactar o arquivo enquanto ele é transferido por FTP. Se você realizar sua transferência desta maneira, você nunca terá o arquivo tar e o conteúdo do tar em seu disco ao mesmo tempo: + + ftp> get tarfile.tar "| tar xvf -" + + Se o seu arquivo tar estiver gzipado, você pode fazer isso também: + + ftp> get tarfile.tar "| zcat | tar xvf -" + + Depois que o conteúdo do seu sistema de arquivos compactado pelo tar estiver no sistema de arquivos da sua memória flash, você poderá desmontar a memória flash e reinicializar: + + # cd / +# umount /flash +# exit + + Assumindo que você configurou seu sistema de arquivos corretamente quando ele foi construído no disco rígido normal (com seus sistemas de arquivos montado como read-only, e com as opções necessárias compiladas no kernel) você agora deve inicializar com sucesso seu sistema embarcado FreeBSD. + + + + + + Estratégias do Sistema para Ambientes Pequenos e Somente Leitura + + Em , foi apontado que o sistema de arquivos /var construído pelo /etc/rc.d/var e a presença de um sistema de arquivos raiz read-only causa problemas com muitos pacotes de software comuns usados ​​com o FreeBSD. Neste artigo, serão fornecidas sugestões para a execução bem-sucedida do cron, do syslog, instalações de ports e do servidor Web Apache. + + + Cron + + Na inicialização, o /var é preenchido pelo /etc/rc.d/var usando a lista disponível em /etc/mtree/BSD.var.dist, então o cron, o cron/tabs, at, e alguns outros diretórios padrões são criados. + + No entanto, isso não resolve o problema de manter as crontabs entre nas reinicializações. Quando o sistema for reinicializado, o sistema de arquivos /var que está na memória desaparecerá e todas as crontabs que você tenha nele também desaparecerão. Portanto, uma solução seria criar crontabs para os usuários que precisam delas, montar seu sistema de arquivos / como read-write e copiar estas crontabs para algum lugar seguro, como /etc/tabs, em seguida, adicione uma linha ao final do /etc/rc.initdiskless que copie estes crontabs para /var/cron/tabs depois que o diretório for criado durante inicialização do sistema. Você também pode precisar adicionar uma linha que altere modos e permissões nos diretórios criados e nos arquivos copiados com /etc/rc.initdiskless. + + + + Syslog + + O syslog.conf especifica os locais de certos arquivos de log que existem em /var/log. Esses arquivos não são criados pelo /etc/rc.d/var na inicialização do sistema. Portanto, em algum lugar do /etc/rc.d/var, logo após a seção que cria os diretórios em /var, você precisará adicionar algo como isto: + + # touch /var/log/security /var/log/maillog /var/log/cron /var/log/messages +# chmod 0644 /var/log/* + + + + Instalação de Ports + + Antes de discutir as alterações necessárias para usar com êxito a árvore de ports, é necessário um lembrete sobre a natureza read-only dos seus sistemas de arquivos na mídia flash. Como eles são read-only, você precisará montá-los temporariamente para read-write usando a sintaxe de montagem mostrada em . Você sempre deve remontar esses sistemas de arquivos no modo read-only quando tiver terminado qualquer manutenção - gravações desnecessárias na mídia flash podem reduzir consideravelmente sua vida útil. + + Para tornar possível entrar em um diretório do ports e executar com sucesso o comando make install, devemos criar um diretório de pacotes em um sistema de arquivos que não esteja localizado na memória o qual manterá o controle dos nossos pacotes entre as reinicializações . Como é necessário montar seus sistemas de arquivos como read-write para a instalação de um pacote, é sensato supor que uma área na mídia flash também possa ser usada para que as informações do pacote sejam gravadas. + + Primeiro, crie o diretório do banco de dados de pacotes. Ele fica normalmente em /var/db/pkg, mas não podemos colocá-lo lá, pois ele irá desaparecer toda vez que o sistema for inicializado. + + # mkdir /etc/pkg + + Agora, adicione uma linha ao arquivo /etc/rc.d/var que vincule o /etc/pkg ao /var/db/pkg. Um exemplo: + + # ln -s /etc/pkg /var/db/pkg + + Agora, sempre que montar seus sistemas de arquivos como read-write e instalar um pacote, o make install funcionará e as informações do pacote serão gravadas com êxito em /etc/pkg (porque o sistema de arquivos será, naquele momento, montado como read-write) que estará sempre disponível para o sistema operacional como /var/db/pkg. + + + + Servidor Web Apache + + + As etapas nesta seção são necessárias apenas se o Apache estiver configurado para gravar suas informações de pid ou log fora do /var. Por padrão, o Apache mantém seu arquivo pid em /var/run/httpd.pid e seus arquivos de log em /var/log. + + + Agora é assumido que o Apache mantém seus arquivos de log em um diretório apache_log_dir fora do /var. Quando esse diretório reside em um sistema de arquivos read-only, o Apache não poderá salvar nenhum arquivo de log e pode ter problemas para funcionar. Se assim for, é necessário adicionar um novo diretório à lista de diretórios em /etc/rc.d/var para criar no /var e vincular apache_log_dir ao /var/log/apache. Também é necessário definir permissões e propriedade neste novo diretório. + + Primeiro, adicione o diretório log/apache à lista de diretórios a serem criados em /etc/rc.d/var. + + Segundo, adicione estes comandos ao /etc/rc.d/var após a seção de criação do diretório: + + # chmod 0774 /var/log/apache +# chown nobody:nobody /var/log/apache + + Por fim, remova o diretório apache_log_dir existente e substitua-o por um link: + + # rm -rf apache_log_dir +# ln -s /var/log/apache apache_log_dir + + +
Added: head/pt_BR.ISO8859-1/articles/solid-state/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/solid-state/pt_BR.po Sun Sep 9 12:48:32 2018 (r52241) @@ -0,0 +1,1030 @@ +# $FreeBSD$ +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Silvio Ap Silva , 2018. #zanata +# Mauro Risonho de Paula Assumpção , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-09 12:37+0000\n" +"PO-Revision-Date: 2018-09-09 11:32+0000\n" +"Last-Translator: Copied by Zanata \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Mauro Risonho de Paula Assumpção, mauro.risonho@gmail.com, 2018\n" +"Silvio Ap Silva, contato@kanazuchi.com, 2018\n" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:35 +msgid "FreeBSD and Solid State Devices" +msgstr "FreeBSD e Dispositivos de Estado Sólido" + +#. (itstool) path: affiliation/address +#: article.translate.xml:44 +#, no-wrap +msgid "" +"\n" +"\t john@kozubik.com\n" +"\t " +msgstr "" +"\n" +"\t john@kozubik.com\n" +"\t " + +#. (itstool) path: authorgroup/author +#: article.translate.xml:38 +msgid "" +" John Kozubik <_:address-1/> " +msgstr "" +" John Kozubik <_:address-1/> " + +#. (itstool) path: info/copyright +#: article.translate.xml:51 +msgid "" +"2001 2009 The FreeBSD Documentation " +"Project" +msgstr "" +"2001 2009 Projeto de Documentação do " +"FreeBSD" + +#. (itstool) path: legalnotice/para +#: article.translate.xml:58 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:60 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." + +#. (itstool) path: legalnotice/title +#: article.translate.xml:70 +msgid "Copyright" +msgstr "Copyright" + +#. (itstool) path: legalnotice/para +#: article.translate.xml:72 +msgid "" +"Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, " +"HTML, PDF, PostScript, RTF and so forth) with or without modification, are " +"permitted provided that the following conditions are met:" +msgstr "" +"Redistribution and use in source (XML DocBook) and 'compiled' forms (XML, " +"HTML, PDF, PostScript, RTF and so forth) with or without modification, are " +"permitted provided that the following conditions are met:" + +#. (itstool) path: listitem/para +#: article.translate.xml:79 +msgid "" +"Redistributions of source code (XML DocBook) must retain the above copyright " +"notice, this list of conditions and the following disclaimer as the first " +"lines of this file unmodified." +msgstr "" +"Redistributions of source code (XML DocBook) must retain the above copyright " +"notice, this list of conditions and the following disclaimer as the first " +"lines of this file unmodified." + +#. (itstool) path: listitem/para +#: article.translate.xml:85 +msgid "" +"Redistributions in compiled form (transformed to other DTDs, converted to " +"PDF, PostScript, RTF and other formats) must reproduce the above copyright " +"notice, this list of conditions and the following disclaimer in the " +"documentation and/or other materials provided with the distribution." +msgstr "" +"Redistributions in compiled form (transformed to other DTDs, converted to " +"PDF, PostScript, RTF and other formats) must reproduce the above copyright " +"notice, this list of conditions and the following disclaimer in the " +"documentation and/or other materials provided with the distribution." + +#. (itstool) path: important/para +#: article.translate.xml:94 +msgid "" +"THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT \"AS IS" +"\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE " +"IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE " +"ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE " +"LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR " +"CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF " +"SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS " +"INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN " +"CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) " +"ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF " +"THE POSSIBILITY OF SUCH DAMAGE." +msgstr "" +"THIS DOCUMENTATION IS PROVIDED BY THE FREEBSD DOCUMENTATION PROJECT \"AS IS" +"\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE " +"IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE " +"ARE DISCLAIMED. IN NO EVENT SHALL THE FREEBSD DOCUMENTATION PROJECT BE " +"LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR " +"CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF " +"SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS " +"INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN " +"CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) " +"ARISING IN ANY WAY OUT OF THE USE OF THIS DOCUMENTATION, EVEN IF ADVISED OF " +"THE POSSIBILITY OF SUCH DAMAGE." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:110 article.translate.xml:112 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/solid-state/article.xml 44923 " +"2014-05-23 17:36:54Z bcr $" +msgstr "$FreeBSD$" + +#. (itstool) path: abstract/para +#: article.translate.xml:115 +msgid "" +"This article covers the use of solid state disk devices in FreeBSD to create " +"embedded systems." +msgstr "" +"Este artigo aborda o uso de dispositivos de disco de estado sólido no " +"FreeBSD para criar sistemas embarcados." + +#. (itstool) path: abstract/para +#: article.translate.xml:118 +msgid "" +"Embedded systems have the advantage of increased stability due to the lack " +"of integral moving parts (hard drives). Account must be taken, however, for " +"the generally low disk space available in the system and the durability of " +"the storage medium." +msgstr "" +"Os sistemas embarcados têm a vantagem de uma maior estabilidade devido à " +"ausência de partes móveis (discos rígidos). No entanto, é preciso ter em " +"conta que o espaço disponível em disco é geralmente baixo no sistema e a " +"durabilidade do meio de armazenamento." + +#. (itstool) path: abstract/para +#: article.translate.xml:124 +msgid "" +"Specific topics to be covered include the types and attributes of solid " +"state media suitable for disk use in FreeBSD, kernel options that are of " +"interest in such an environment, the rc.initdiskless " +"mechanisms that automate the initialization of such systems and the need for " +"read-only filesystems, and building filesystems from scratch. The article " +"will conclude with some general strategies for small and read-only FreeBSD " +"environments." +msgstr "" +"Tópicos específicos a serem abordados incluem os tipos e atributos das mídia " +"de estado sólido adequadas para uso como disco no FreeBSD, opções de kernel " +"que são de interesse em tal ambiente, os mecanismos rc." +"initdiskless que automatizam a inicialização de tais sistemas e a " +"necessidade de sistemas de arquivos read-only e a construção de sistemas de " +"arquivos a partir do zero. O artigo será concluído com algumas estratégias " +"gerais para ambientes FreeBSD pequenos e read-only ." + +#. (itstool) path: sect1/title +#: article.translate.xml:136 +msgid "Solid State Disk Devices" +msgstr "Dispositivos de Disco de Estado Sólido" + +#. (itstool) path: sect1/para +#: article.translate.xml:138 +msgid "" +"The scope of this article will be limited to solid state disk devices made " +"from flash memory. Flash memory is a solid state memory (no moving parts) " +"that is non-volatile (the memory maintains data even after all power sources " +"have been disconnected). Flash memory can withstand tremendous physical " +"shock and is reasonably fast (the flash memory solutions covered in this " +"article are slightly slower than a EIDE hard disk for write operations, and " +"much faster for read operations). One very important aspect of flash memory, " +"the ramifications of which will be discussed later in this article, is that " +"each sector has a limited rewrite capacity. You can only write, erase, and " +"write again to a sector of flash memory a certain number of times before the " +"sector becomes permanently unusable. Although many flash memory products " +"automatically map bad blocks, and although some even distribute write " +"operations evenly throughout the unit, the fact remains that there exists a " +"limit to the amount of writing that can be done to the device. Competitive " +"units have between 1,000,000 and 10,000,000 writes per sector in their " +"specification. This figure varies due to the temperature of the environment." +msgstr "" +"O escopo deste artigo será limitado a dispositivos de disco de estado sólido " +"feitos de memória flash. A memória flash é uma memória de estado sólido (sem " +"partes móveis) que é não volátil (a memória mantém os dados mesmo depois de " +"todas as fontes de energia terem sido desconectadas). A memória flash pode " +"suportar um enorme choque físico e é razoavelmente rápida (as soluções de " +"memória flash abordadas neste artigo são um pouco mais lentas que um disco " +"rígido EIDE para operações de gravação e muito mais rápidas para operações " +"de leitura). Um aspecto muito importante da memória flash, cujas " +"ramificações serão discutidas mais adiante neste artigo, é que cada setor " +"tem uma capacidade limitada de reescrita. Você só pode gravar, apagar e " +"gravar novamente em um setor de memória flash um certo número de vezes antes " +"que o setor fique permanentemente inutilizável. Embora muitos produtos de " +"memória flash mapeiam automaticamente os blocos defeituosos, e embora alguns " +"até distribuam operações de gravação uniformemente por toda a unidade, a " +"verdade é que existe um limite para a quantidade de escrita que pode ser " +"feita no dispositivo. Unidades competitivas possuem entre 1.000.000 e " +"10.000.000 gravações por setor em suas especificações. Este valor varia com " +"à temperatura do ambiente." + +#. (itstool) path: sect1/para +#: article.translate.xml:159 +msgid "" +"Specifically, we will be discussing ATA compatible compact-flash units, " +"which are quite popular as storage media for digital cameras. Of particular " +"interest is the fact that they pin out directly to the IDE bus and are " +"compatible with the ATA command set. Therefore, with a very simple and low-" +"cost adaptor, these devices can be attached directly to an IDE bus in a " +"computer. Once implemented in this manner, operating systems such as FreeBSD " +"see the device as a normal hard disk (albeit small)." +msgstr "" +"Especificamente, estaremos discutindo unidades compact-flash compatíveis com " +"ATA, as quais são bastante populares como mídia de armazenamento para " +"câmeras digitais. De particular interesse é o fato de que eles são fixados " +"diretamente no barramento IDE e são compatíveis com o conjunto de comandos " +"ATA. Portanto, com um adaptador muito simples e de baixo custo, esses " +"dispositivos podem ser conectados diretamente a um barramento IDE em um " +"computador. Uma vez implementado desta maneira, sistemas operacionais como o " +"FreeBSD vêem o dispositivo como um disco rígido normal (embora pequeno)." + +#. (itstool) path: sect1/para +#: article.translate.xml:169 +msgid "" +"Other solid state disk solutions do exist, but their expense, obscurity, and " +"relative unease of use places them beyond the scope of this article." +msgstr "" +"Outras soluções de disco de estado sólido existem, mas seu custo, " +"obscuridade e relativa dificuldade de uso os colocam além do escopo deste " +"artigo." + +#. (itstool) path: sect1/title +#: article.translate.xml:175 +msgid "Kernel Options" +msgstr "Opções do Kernel" + +#. (itstool) path: sect1/para +#: article.translate.xml:177 +msgid "" +"A few kernel options are of specific interest to those creating an embedded " +"FreeBSD system." +msgstr "" +"Algumas opções do kernel são de interesse específico para aqueles que criam " +"sistemas FreeBSD embarcados." + +#. (itstool) path: sect1/para +#: article.translate.xml:180 +msgid "" +"All embedded FreeBSD systems that use flash memory as system disk will be " +"interested in memory disks and memory filesystems. Because of the limited " +"number of writes that can be done to flash memory, the disk and the " +"filesystems on the disk will most likely be mounted read-only. In this " +"environment, filesystems such as /tmp and /" +"var are mounted as memory filesystems to allow the system to " +"create logs and update counters and temporary files. Memory filesystems are " +"a critical component to a successful solid state FreeBSD implementation." +msgstr "" +"Todos os sistemas embarcados FreeBSD que usam memória flash como disco para " +"o sistema estarão interessados ​​em usar discos em memória e sistemas de " +"arquivos em memória. Devido ao número limitado de gravações que podem ser " +"feitas na memória flash, o disco e os sistemas de arquivos no disco " +"provavelmente serão montados como read-only. Nesse ambiente, sistemas de " +"arquivos tais como /tmp e /var são " +"montados como sistemas de arquivos em memória para permitir que o sistema " +"crie logs e atualize contadores e arquivos temporários. Os sistemas de " +"arquivos em memória são um componente crítico para uma implementação bem-" +"sucedida do FreeBSD em dispositivos de estado sólido." + +#. (itstool) path: sect1/para +#: article.translate.xml:191 +msgid "" +"You should make sure the following lines exist in your kernel configuration " +"file:" +msgstr "" +"Você deve ter certeza de que as seguintes linhas existem no seu arquivo de " +"configuração do kernel:" + +#. (itstool) path: sect1/programlisting +#: article.translate.xml:194 +#, no-wrap +msgid "" +"options MFS # Memory Filesystem\n" +"options MD_ROOT # md device usable as a potential root device\n" +"pseudo-device md # memory disk" +msgstr "" +"options MFS # Memory Filesystem\n" +"options MD_ROOT # md device usable as a potential root device\n" +"pseudo-device md # memory disk" + +#. (itstool) path: sect1/title +#: article.translate.xml:200 +msgid "The rc Subsystem and Read-Only Filesystems" +msgstr "O Subsistema rc e os Sistemas de Arquivos Read-Only" + +#. (itstool) path: sect1/para +#: article.translate.xml:203 +msgid "" +"The post-boot initialization of an embedded FreeBSD system is controlled by " +"/etc/rc.initdiskless." +msgstr "" +"A inicialização pós-boot de um sistema FreeBSD embarcado é controlada por " +"/etc/rc.initdiskless." + +#. (itstool) path: sect1/para +#: article.translate.xml:206 +msgid "" +"/etc/rc.d/var mounts /var as a " +"memory filesystem, makes a configurable list of directories in /" +"var with the mkdir1 command, and changes " +"modes on some of those directories. In the execution of /etc/rc.d/" +"var, one other rc.conf variable comes into " +"play – varsize. A /var partition is " +"created by /etc/rc.d/var based on the value of this " +"variable in rc.conf:" +msgstr "" +"O /etc/rc.d/var monta o /var como " +"um sistema de arquivos em memória, cria uma lista configurável de diretórios " +"em /var com o comando " +"mkdir1 e altera os modos em alguns desses diretórios. Na execução do " +"/etc/rc.d/var, uma outra variável rc.conf entra em jogo – varsize. Uma partição " +"/var é criada por /etc/rc.d/var " +"baseado no valor desta variável em rc.conf:" + +#. (itstool) path: sect1/programlisting +#: article.translate.xml:218 +#, no-wrap +msgid "varsize=8192" +msgstr "varsize=8192" + +#. (itstool) path: sect1/para +#: article.translate.xml:220 +msgid "Remember that this value is in sectors by default." +msgstr "Lembre-se de que esse valor é informado em setores, por padrão." + +#. (itstool) path: sect1/para +#: article.translate.xml:222 +msgid "" +"The fact that /var is a read-write filesystem is an " +"important distinction, as the / partition (and any " +"other partitions you may have on your flash media) should be mounted read-" +"only. Remember that in we detailed the limitations " +"of flash memory - specifically the limited write capability. The importance " +"of not mounting filesystems on flash media read-write, and the importance of " +"not using a swap file, cannot be overstated. A swap file on a busy system " +"can burn through a piece of flash media in less than one year. Heavy logging " +"or temporary file creation and destruction can do the same. Therefore, in " +"addition to removing the swap entry from your /" +"etc/fstab, you should also change the Options field for each " +"filesystem to ro as follows:" +msgstr "" +"O fato do /var ser um sistema de arquivos read-write é " +"uma distinção importante, pois a partição / (e " +"quaisquer outras partições que você possa ter em sua mídia flash) deve ser " +"montada como read-only. Lembre-se que em " +"detalhamos as limitações da memória flash - especificamente a capacidade de " +"gravação limitada. A importância de não montar sistemas de arquivos em mídia " +"flash em modo read-write, e a importância de não usar um arquivo de swap, " +"não pode ser exagerado. Um arquivo de swap em um sistema ocupado pode " +"inutilizar uma mídia flash em menos de um ano. Criação de log pesado ou " +"criação e destruição de arquivos temporários podem fazer o mesmo. Portanto, " +"além de remover a entrada swap do seu /etc/" +"fstab, você também deve alterar o campo Options para cada sistema " +"de arquivos para ro como segue:" + +#. (itstool) path: sect1/programlisting +#: article.translate.xml:239 +#, no-wrap +msgid "" +"# Device Mountpoint FStype Options Dump Pass#\n" +"/dev/ad0s1a / ufs ro 1 1" +msgstr "" +"# Device Mountpoint FStype Options Dump Pass#\n" +"/dev/ad0s1a / ufs ro 1 1" + +#. (itstool) path: sect1/para +#: article.translate.xml:242 +msgid "" +"A few applications in the average system will immediately begin to fail as a " +"result of this change. For instance, cron will not run properly as a result " +"of missing cron tabs in the /var created by /" +"etc/rc.d/var, and syslog and dhcp will encounter problems as well " +"as a result of the read-only filesystem and missing items in the /" +"var that /etc/rc.d/var has created. These " +"are only temporary problems though, and are addressed, along with solutions " +"to the execution of other common software packages in ." +msgstr "" +"Alguns aplicativos no sistema começarão a falhar imediatamente como " +"resultado desta alteração. Por exemplo, o cron não será executado " +"corretamente como resultado da falta de crontabs no /var criado pelo /etc/rc.d/var, o syslog e o dhcp " +"também irão encontrar problemas como resultado do sistema de arquivos estar " +"em modo read-only e dos itens ausentes no /var que o " +"/etc/rc.d/var criou. Estes são apenas problemas " +"temporários, embora sejam abordados, juntamente com soluções para a execução " +"de outros pacotes de software comuns em ." + +#. (itstool) path: sect1/para +#: article.translate.xml:254 +msgid "" +"An important thing to remember is that a filesystem that was mounted read-" +"only with /etc/fstab can be made read-write at any time " +"by issuing the command:" +msgstr "" +"Uma coisa importante para lembrar é que um sistema de arquivos que foi " +"montado como read-only com o /etc/fstab pode ser " +"colocado em modo read-write a qualquer momento, executando o comando:" + +#. (itstool) path: sect1/screen +#: article.translate.xml:258 +#, no-wrap +msgid "# /sbin/mount -uw partition" +msgstr "# /sbin/mount -uw partition" + +#. (itstool) path: sect1/para +#: article.translate.xml:260 +msgid "and can be toggled back to read-only with the command:" +msgstr "e pode ser alternado de volta para somente leitura com o comando:" + +#. (itstool) path: sect1/screen +#: article.translate.xml:263 +#, no-wrap +msgid "# /sbin/mount -ur partition" +msgstr "# /sbin/mount -ur partition" + +#. (itstool) path: sect1/title +#: article.translate.xml:267 +msgid "Building a File System from Scratch" +msgstr "Construindo um sistema de arquivos a partir do zero" + +#. (itstool) path: sect1/para +#: article.translate.xml:269 +msgid "" +"Because ATA compatible compact-flash cards are seen by FreeBSD as normal IDE " +"hard drives, you could theoretically install FreeBSD from the network using " +"the kern and mfsroot floppies or from a CD." +msgstr "" +"Como os cartões Compact Flash compatíveis com ATA são vistos pelo FreeBSD " +"como discos rígidos IDE normais, você poderia teoricamente instalar o " +"FreeBSD a partir da rede usando o os disquetes do kern e mfsroot ou de um CD." + +#. (itstool) path: sect1/para +#: article.translate.xml:274 +msgid "" +"However, even a small installation of FreeBSD using normal installation " +"procedures can produce a system in size of greater than 200 megabytes. " +"Because most people will be using smaller flash memory devices (128 " +"megabytes is considered fairly large - 32 or even 16 megabytes is common) an " +"installation using normal mechanisms is not possible—there is simply not " +"enough disk space for even the smallest of conventional installations." +msgstr "" +"No entanto, mesmo uma pequena instalação do FreeBSD utilizando procedimentos " +"normais de instalação pode produzir um sistema com tamanho maior que 200 " +"megabytes. Como a maioria das pessoas usará dispositivos de memória flash " +"menores (128 megabytes são considerados razoavelmente grandes - 32 ou até " +"mesmo 16 megabytes são comuns), uma instalação usando mecanismos normais não " +"será possível - simplesmente não há espaço em disco suficiente nem para as " +"menores instalações convencionais." + +#. (itstool) path: sect1/para +#: article.translate.xml:283 +msgid "" +"The easiest way to overcome this space limitation is to install FreeBSD " +"using conventional means to a normal hard disk. After the installation is " +"complete, pare down the operating system to a size that will fit onto your " +"flash media, then tar the entire filesystem. The following steps will guide " +"you through the process of preparing a piece of flash memory for your tarred " +"filesystem. Remember, because a normal installation is not being performed, " +"operations such as partitioning, labeling, file-system creation, etc. need " +"to be performed by hand. In addition to the kern and mfsroot floppy disks, " +"you will also need to use the fixit floppy." +msgstr "" +"A maneira mais fácil de superar essa limitação de espaço é instalar o " +"FreeBSD usando meios convencionais em um disco rígido normal. Após a " +"conclusão da instalação, reduza o sistema operacional para um tamanho que " +"caiba na mídia flash e compacte o sistema de arquivos inteiro com o tar. Os " +"passos seguintes irão guiá-lo através do processo de preparação de uma parte " +"da memória flash para o seu sistema de arquivos compactado com o tar. Lembre-" +"se de que não estamos executando uma instalação normal, logo as operações " +"como particionamento, criação dos labels, criação do sistema de arquivos, " +"etc. precisam ser executadas manualmente. Além dos disquetes do kern e " +"mfsroot, você também precisará usar o disquete do fixit." + +#. (itstool) path: step/title +#: article.translate.xml:297 +msgid "Partitioning Your Flash Media Device" +msgstr "Particionando seu Dispositivo de Mídia Flash" + +#. (itstool) path: step/para +#: article.translate.xml:299 +msgid "" +"After booting with the kern and mfsroot floppies, choose custom from the installation menu. In the custom installation menu, choose " +"partition. In the partition menu, you should delete all " +"existing partitions using d. After deleting all existing " +"partitions, create a partition using c and accept the " +"default value for the size of the partition. When asked for the type of the " +"partition, make sure the value is set to 165. Now write " +"this partition table to the disk by pressing w (this is a " +"hidden option on this screen). If you are using an ATA compatible compact " +"flash card, you should choose the FreeBSD Boot Manager. Now press q to quit the partition menu. You will be shown the boot manager menu " +"once more - repeat the choice you made earlier." +msgstr "" +"Após inicializar com os disquetes do kern e mfsroot, escolha " +"custom no menu de instalação. No menu de instalação " +"personalizada, escolha partition. No menu de partições, " +"você deve apagar todas as partições existentes usando a tecla d. Depois de excluir todas as partições existentes, crie uma partição " +"usando a tecla c e aceite o valor padrão para o tamanho da " +"partição. Quando perguntado sobre o tipo da partição, certifique-se de que o " +"valor esteja configurado para 165. Agora escreva esta " +"tabela de partições no disco pressionando w (esta é uma " +"opção oculta nesta tela). Se você estiver usando um cartão compact flash " +"compatível com ATA, deverá escolher o FreeBSD Boot Manager. Agora pressione " +"q para sair do menu de partições. Você verá novamente o " +"menu do gerenciador de inicialização - repita a escolha feita anteriormente." + +#. (itstool) path: step/title +#: article.translate.xml:319 +msgid "Creating Filesystems on Your Flash Memory Device" +msgstr "Criando Sistemas de Arquivos em seu Dispositivo de Memória Flash" + +#. (itstool) path: step/para +#: article.translate.xml:322 +msgid "" +"Exit the custom installation menu, and from the main installation menu " +"choose the fixit option. After entering the fixit " +"environment, enter the following command:" +msgstr "" +"Saia do menu de instalação personalizada e, no menu de instalação principal, " +"escolha a opção fixit. Depois de entrar no ambiente do " +"fixit, digite o seguinte comando:" + +#. (itstool) path: step/screen +#: article.translate.xml:327 +#, no-wrap +msgid "# disklabel -e /dev/ad0c" +msgstr "# disklabel -e /dev/ad0c" + +#. (itstool) path: step/para +#: article.translate.xml:329 +msgid "" +"At this point you will have entered the vi editor under the auspices of the " +"disklabel command. Next, you need to add an a: line at " +"the end of the file. This a: line should look like:" +msgstr "" +"Neste ponto, você terá entrado no editor vi sob os auspícios do comando " +"disklabel. Em seguida, você precisa adicionar uma linha a: no final do arquivo. Esta linha a: deve ser " +"semelhante a linha abaixo:" + +#. (itstool) path: step/programlisting +#: article.translate.xml:334 +#, no-wrap +msgid "a: 123456 0 4.2BSD 0 0" +msgstr "a: 123456 0 4.2BSD 0 0" + +#. (itstool) path: step/para +#: article.translate.xml:336 +msgid "" +"Where 123456 is a number that is exactly the same " +"as the number in the existing c: entry for size. " +"Basically you are duplicating the existing c: line as an " +"a: line, making sure that fstype is 4.2BSD. Save the file and exit." +msgstr "" +"Onde 123456 é um número o qual é exatamente o " +"mesmo que o número existente na entrada c: para o " +"tamanho. Basicamente, você está duplicando a linha c: " +"existente como uma linha a:, certifique-se de que o " +"fstype seja 4.2BSD. Salve o arquivo e saia." + +#. (itstool) path: step/screen +#: article.translate.xml:343 +#, no-wrap +msgid "" +"# disklabel -B -r /dev/ad0c\n" +"# newfs /dev/ad0a" +msgstr "" +"# disklabel -B -r /dev/ad0c\n" +"# newfs /dev/ad0a" + +#. (itstool) path: step/title +#: article.translate.xml:348 +msgid "Placing Your Filesystem on the Flash Media" +msgstr "Colocando seu Sistema de Arquivos na Mídia Flash" + +#. (itstool) path: step/para +#: article.translate.xml:350 +msgid "Mount the newly prepared flash media:" +msgstr "Monte a mídia flash recém-preparada:" + +#. (itstool) path: step/screen +#: article.translate.xml:352 +#, no-wrap +msgid "# mount /dev/ad0a /flash" +msgstr "# mount /dev/ad0a /flash" + +#. (itstool) path: step/para +#: article.translate.xml:354 +msgid "" +"Bring this machine up on the network so we may transfer our tar file and " +"explode it onto our flash media filesystem. One example of how to do this is:" +msgstr "" +"Coloque esta máquina na rede para que possamos transferir nosso arquivo tar " +"e extrai-lo em nosso sistema de arquivos de mídia flash. Um exemplo de como " +"fazer isso é:" + +#. (itstool) path: step/screen +#: article.translate.xml:358 +#, no-wrap +msgid "" +"# ifconfig xl0 192.168.0.10 netmask 255.255.255.0\n" +"# route add default 192.168.0.1" +msgstr "" +"# ifconfig xl0 192.168.0.10 netmask 255.255.255.0\n" +"# route add default 192.168.0.1" + +#. (itstool) path: step/para +#: article.translate.xml:361 +msgid "" +"Now that the machine is on the network, transfer your tar file. You may be " +"faced with a bit of a dilemma at this point - if your flash memory part is " +"128 megabytes, for instance, and your tar file is larger than 64 megabytes, " +"you cannot have your tar file on the flash media at the same time as you " +"explode it - you will run out of space. One solution to this problem, if you " +"are using FTP, is to untar the file while it is transferred over FTP. If you " +"perform your transfer in this manner, you will never have the tar file and " +"the tar contents on your disk at the same time:" +msgstr "" +"Agora que a máquina está na rede, transfira seu arquivo tar. Você pode se " +"deparar com um pequeno dilema neste ponto - se a sua memória flash tiver por " +"exemplo 128 megabytes, e seu arquivo tar for maior que 64 megabytes, você " +"não poderá ter o seu arquivo tar na mídia flash ao mesmo tempo em que " +"realiza a descompressão - você ficará sem espaço. Uma solução para esse " +"problema, se você estiver usando FTP, é descompactar o arquivo enquanto ele " +"é transferido por FTP. Se você realizar sua transferência desta maneira, " +"você nunca terá o arquivo tar e o conteúdo do tar em seu disco ao mesmo " +"tempo:" + +#. (itstool) path: step/screen +#: article.translate.xml:373 +#, no-wrap +msgid "ftp> get tarfile.tar \"| tar xvf -\"" +msgstr "ftp> get tarfile.tar \"| tar xvf -\"" + +#. (itstool) path: step/para +#: article.translate.xml:375 +msgid "If your tarfile is gzipped, you can accomplish this as well:" *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Mon Sep 10 06:02:41 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61AC010802A2; Mon, 10 Sep 2018 06:02:41 +0000 (UTC) (envelope-from rcyu@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F10071028; Mon, 10 Sep 2018 06:02:41 +0000 (UTC) (envelope-from rcyu@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 086C7246DA; Mon, 10 Sep 2018 06:02:41 +0000 (UTC) (envelope-from rcyu@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8A62efZ019915; Mon, 10 Sep 2018 06:02:40 GMT (envelope-from rcyu@FreeBSD.org) Received: (from rcyu@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8A62e6A019914; Mon, 10 Sep 2018 06:02:40 GMT (envelope-from rcyu@FreeBSD.org) Message-Id: <201809100602.w8A62e6A019914@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: rcyu set sender to rcyu@FreeBSD.org using -f From: Ruey-Cherng Yu Date: Mon, 10 Sep 2018 06:02:40 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52242 - head/zh_TW.UTF-8/share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: rcyu X-SVN-Commit-Paths: head/zh_TW.UTF-8/share/xml X-SVN-Commit-Revision: 52242 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 06:02:41 -0000 Author: rcyu Date: Mon Sep 10 06:02:40 2018 New Revision: 52242 URL: https://svnweb.freebsd.org/changeset/doc/52242 Log: - Traditional Chinese translation of the latest news item (September 2nd) Modified: head/zh_TW.UTF-8/share/xml/news.xml Modified: head/zh_TW.UTF-8/share/xml/news.xml ============================================================================== --- head/zh_TW.UTF-8/share/xml/news.xml Sun Sep 9 12:48:32 2018 (r52241) +++ head/zh_TW.UTF-8/share/xml/news.xml Mon Sep 10 06:02:40 2018 (r52242) @@ -34,6 +34,19 @@ 2018 + 9 + + + 2 + +

æ–°ä»» committer: + Kevin Bowling + (ports)

+ + + + + 8 From owner-svn-doc-all@freebsd.org Mon Sep 10 17:05:46 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5155B1096236; Mon, 10 Sep 2018 17:05:46 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 084048BD66; Mon, 10 Sep 2018 17:05:46 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id F342633C4; Mon, 10 Sep 2018 17:05:45 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8AH5jQB098816; Mon, 10 Sep 2018 17:05:45 GMT (envelope-from gjb@FreeBSD.org) Received: (from gjb@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8AH5jax098815; Mon, 10 Sep 2018 17:05:45 GMT (envelope-from gjb@FreeBSD.org) Message-Id: <201809101705.w8AH5jax098815@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gjb set sender to gjb@FreeBSD.org using -f From: Glen Barber Date: Mon, 10 Sep 2018 17:05:45 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52243 - head/en_US.ISO8859-1/htdocs/releases/12.0R/hardware X-SVN-Group: doc-head X-SVN-Commit-Author: gjb X-SVN-Commit-Paths: head/en_US.ISO8859-1/htdocs/releases/12.0R/hardware X-SVN-Commit-Revision: 52243 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2018 17:05:46 -0000 Author: gjb Date: Mon Sep 10 17:05:45 2018 New Revision: 52243 URL: https://svnweb.freebsd.org/changeset/doc/52243 Log: Move variables specific to manual pages to be nested within the target match evaluation of ${DOC}.html. This is an attempt to fix what appears to be an intermittent build race condition. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/htdocs/releases/12.0R/hardware/Makefile Modified: head/en_US.ISO8859-1/htdocs/releases/12.0R/hardware/Makefile ============================================================================== --- head/en_US.ISO8859-1/htdocs/releases/12.0R/hardware/Makefile Mon Sep 10 06:02:40 2018 (r52242) +++ head/en_US.ISO8859-1/htdocs/releases/12.0R/hardware/Makefile Mon Sep 10 17:05:45 2018 (r52243) @@ -7,13 +7,6 @@ .include "../Makefile.hardware" .endif -MAN4TMP!= ${MKTEMP} -d ${.CURDIR}/svn.XXXXXXXX -MAN4DIR= ${MAN4TMP} -.if exists(${MAN4DIR}) - rm -rf ${MAN4DIR} -.endif - -MAN4PAGES?= ${MAN4DIR}/*.4 ${MAN4DIR}/man4.*/*.4 ARCHLIST?= ${DOC_PREFIX}/share/misc/dev.archlist.txt MAN2HWNOTES_CMD=${DOC_PREFIX}/share/misc/man2hwnotes.pl @@ -31,11 +24,17 @@ INSTALL_ONLY_COMPRESSED= CLEANDIRS+= ${.CURDIR}/svn.* .if ${.TARGET:M${DOC}.html} +MAN4TMP!= ${MKTEMP} -d ${.CURDIR}/svn.XXXXXXXX +MAN4DIR= ${MAN4TMP} +.if exists(${MAN4DIR}) + rm -rf ${MAN4DIR} +.endif + +MAN4PAGES?= ${MAN4DIR}/*.4 ${MAN4DIR}/man4.*/*.4 hardware.parsed.xml: dev-auto.ent man4-rmsrc dev-auto.ent: man4-src-checkout ${PERL} ${MAN2HWNOTES_CMD} ${MAN2HWNOTES_FLAGS} -a ${ARCHLIST} -o ${.TARGET} ${MAN4PAGES} || (rm -f ${.TARGET}) CLEANFILES+= dev-auto.ent -.endif man4-src-checkout: mkdir -p ${MAN4TMP} @@ -45,5 +44,6 @@ man4-src-checkout: man4-rmsrc: @# Just in case. rm -rf ${MAN4DIR} || true +.endif .include "${DOC_PREFIX}/share/mk/doc.project.mk" From owner-svn-doc-all@freebsd.org Tue Sep 11 07:43:12 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DBADA1082749; Tue, 11 Sep 2018 07:43:12 +0000 (UTC) (envelope-from manu@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 917608A63C; Tue, 11 Sep 2018 07:43:12 +0000 (UTC) (envelope-from manu@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 8C62814D66; Tue, 11 Sep 2018 07:43:12 +0000 (UTC) (envelope-from manu@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8B7hCCB054540; Tue, 11 Sep 2018 07:43:12 GMT (envelope-from manu@FreeBSD.org) Received: (from manu@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8B7hCd7054539; Tue, 11 Sep 2018 07:43:12 GMT (envelope-from manu@FreeBSD.org) Message-Id: <201809110743.w8B7hCd7054539@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: manu set sender to manu@FreeBSD.org using -f From: Emmanuel Vadot Date: Tue, 11 Sep 2018 07:43:12 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52244 - head/share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: manu X-SVN-Commit-Paths: head/share/xml X-SVN-Commit-Revision: 52244 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 07:43:13 -0000 Author: manu (src,ports committer) Date: Tue Sep 11 07:43:12 2018 New Revision: 52244 URL: https://svnweb.freebsd.org/changeset/doc/52244 Log: Add news entry about my commit bit upgrade Approved by: bapt (mentor) Modified: head/share/xml/news.xml Modified: head/share/xml/news.xml ============================================================================== --- head/share/xml/news.xml Mon Sep 10 17:05:45 2018 (r52243) +++ head/share/xml/news.xml Tue Sep 11 07:43:12 2018 (r52244) @@ -35,6 +35,14 @@ 9 + 6 + +

New committer: + Emmanuel Vadot + (ports)

+ + + 2

New committer: From owner-svn-doc-all@freebsd.org Tue Sep 11 15:02:02 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92F931093A4B; Tue, 11 Sep 2018 15:02:02 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 478A07AA57; Tue, 11 Sep 2018 15:02:02 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 427D71954B; Tue, 11 Sep 2018 15:02:02 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8BF22nL081085; Tue, 11 Sep 2018 15:02:02 GMT (envelope-from gjb@FreeBSD.org) Received: (from gjb@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8BF22kg081084; Tue, 11 Sep 2018 15:02:02 GMT (envelope-from gjb@FreeBSD.org) Message-Id: <201809111502.w8BF22kg081084@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gjb set sender to gjb@FreeBSD.org using -f From: Glen Barber Date: Tue, 11 Sep 2018 15:02:02 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52245 - head/en_US.ISO8859-1/htdocs/releases/11.2R X-SVN-Group: doc-head X-SVN-Commit-Author: gjb X-SVN-Commit-Paths: head/en_US.ISO8859-1/htdocs/releases/11.2R X-SVN-Commit-Revision: 52245 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 15:02:02 -0000 Author: gjb Date: Tue Sep 11 15:02:01 2018 New Revision: 52245 URL: https://svnweb.freebsd.org/changeset/doc/52245 Log: Regen after r338587. PR: 231270 Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html Modified: head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html ============================================================================== --- head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html Tue Sep 11 07:43:12 2018 (r52244) +++ head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html Tue Sep 11 15:02:01 2018 (r52245) @@ -13,7 +13,7 @@ as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the - “®” symbol.

Last modified on 2018-06-28 11:30:52 EDT by gjb.
Abstract

This document lists errata items for FreeBSD 11.2-RELEASE, + “®” symbol.

Last modified on 2018-09-11 11:00:17 EDT by gjb.
Abstract

This document lists errata items for FreeBSD 11.2-RELEASE, containing significant information discovered after the release or too late in the release cycle to be otherwise included in the release documentation. This information @@ -76,9 +76,9 @@ boot

[2018-06-26] An issue had been discovered late in the release cycle where a system crash could occur after - installing emulators/virtualbox-ose from - upstream package mirrors via pkg(8).

Building emulators/virtualbox-ose from - the ports(7) collection has been observed to work + installing emulators/virtualbox-ose-kmod + from upstream package mirrors via pkg(8).

Building emulators/virtualbox-ose-kmod + from the ports(7) collection has been observed to work around the crash.

See PR 228535 for more information.

  • [2018-06-26] It was discovered after the releng/11.2 branch was tagged for FreeBSD 11.2-RELEASE that a few device drivers were From owner-svn-doc-all@freebsd.org Tue Sep 11 18:40:24 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91C3D1099470; Tue, 11 Sep 2018 18:40:24 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3642A8345D; Tue, 11 Sep 2018 18:40:24 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2D8991B93C; Tue, 11 Sep 2018 18:40:24 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8BIeONd093512; Tue, 11 Sep 2018 18:40:24 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8BIeO2Z093511; Tue, 11 Sep 2018 18:40:24 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201809111840.w8BIeO2Z093511@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Tue, 11 Sep 2018 18:40:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52246 - head/de_DE.ISO8859-1/books/handbook/introduction X-SVN-Group: doc-head X-SVN-Commit-Author: bhd X-SVN-Commit-Paths: head/de_DE.ISO8859-1/books/handbook/introduction X-SVN-Commit-Revision: 52246 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 18:40:24 -0000 Author: bhd Date: Tue Sep 11 18:40:23 2018 New Revision: 52246 URL: https://svnweb.freebsd.org/changeset/doc/52246 Log: Update to r51981: Improve the introduction chapter, to fix the overall structure of that part. The diff is a bit large due to changed indentation, but it's mostly about moving the a bit further down and shortening the introduction part. Modified: head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml Tue Sep 11 15:02:01 2018 (r52245) +++ head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml Tue Sep 11 18:40:23 2018 (r52246) @@ -4,7 +4,7 @@ The FreeBSD German Documentation Project $FreeBSD$ - basiert auf: r51969 + basiert auf: r51981 --> 4.4BSD-Lite - &os; ist ein Open Source, Unix-ähnliches Betriebssystem für - x86 (32 und 64 Bit) &arm;, AARch64, &risc-v;, &mips;, &power;, - &powerpc; und Sun &ultrasparc; Rechner, das ursprünglich auf - 4.4BSD-Lite basiert. Mehr zur Geschichte von &os; erfahren Sie in die Geschichte von &os; oder aus den - aktuellen - Release-Informationen. Falls Sie das &os; Projekt - unterstützen wollen (z.B. mit Quellcode, Hardware- oder - Geldspenden), lesen Sie den &os; - unterstützen Artikel. + &os; ist ein offenes, standardkonformes Unix-ähnliches + Betriebssystem für x86 (32 und 64 Bit) &arm;, AARch64, &risc-v;, + &mips;, &power;, &powerpc; und Sun &ultrasparc; Rechner. Es + bietet alle Funktionen, die heutzutage als selbstverständlich + angesehen werden, wie präemptives Multitasking, Speicherschutz, + virtueller Speicher, Mehrbenutzerfunktionen, SMP-Unterstützung, + Open Source Entwicklungswerkzeuge für verschiedene Sprachen und + Frameworks sowie Desktop-Funktionen rund um das X Window System, + KDE und GNOME. Besondere Eigenschaften sind: - - Was kann &os;? + + + Liberale Open Source Lizenz, die + Ihnen das Recht einräumt, den Quellcode frei zu + modifizieren und zu erweitern und ihn in freien oder + proprietären Produkten zu integrieren, ohne dabei den + für Copyleft-Lizenzen typischen Einschränkungen zu + unterliegen. Ebenso sollen mögliche + Inkompatibilitätsprobleme vermieden werden. + - &os; ist ein offenes, standardkonformes Unix-ähnliches - Betriebssystem. Es bietet alle Funktionen, die heutzutage als - selbstverständlich angesehen werden, wie präemptives - Multitasking, Speicherschutz, virtueller Speicher, - Mehrbenutzerfunktionen, SMP-Unterstützung, Open Source - Entwicklungswerkzeuge für verschiedene Sprachen und - Frameworks sowie Desktop-Funktionen rund um das - X Window System, KDE und GNOME. Besondere Eigenschaften - sind: + + Starke TCP/IP-Netzwerkfähigkeit + + TCP/IP-Netzwerkfähigkeit - &os; + implementiert Industrie-Standardprotokolle mit immer + höherer Leistung und Skalierbarkeit. Dies macht &os; zu + einer exzellenten Lösung sowohl für Server, als auch für + Routing/Firewall Aufgaben. Tatsächlich nutzen viele + Unternehmen und Anbieter &os; zu genau + diesem Zweck. + - - - Liberale Open Source Lizenz, die - Ihnen das Recht einräumt, den Quellcode frei zu - modifizieren und zu erweitern und ihn in freien oder - proprietären Produkten zu integrieren, ohne dabei den - für Copyleft-Lizenzen typischen Einschränkungen zu - unterliegen. Ebenso sollen mögliche - Inkompatibilitätsprobleme vermieden werden. - + + Vollständig integrierte + OpenZFS-Unterstützung, einschließlich + root-on-ZFS, ZFS Boot Environments, Fehlermanagement, + administrative Delegation, Unterstützung für Jails, + &os;-spezifische Dokumentation und Unterstützung im + System-Installationsprogramm. + - - Starke TCP/IP-Netzwerkfähigkeit - - TCP/IP-Netzwerkfähigkeit - &os; - implementiert Industrie-Standardprotokolle mit immer - höherer Leistung und Skalierbarkeit. Dies macht &os; zu - einer exzellenten Lösung sowohl für Server, als auch für - Routing/Firewall Aufgaben. Tatsächlich nutzen viele - Unternehmen und Anbieter &os; zu genau - diesem Zweck. - + + Umfangreiche + Sicherheitsfunktionen, vom System für die + verbindliche Zugriffskontrolle (Mandatory Access Control, + MAC), bis hin zu Capsicum und + Sandbox-Mechanismen. + - - Vollständig integrierte - OpenZFS-Unterstützung, einschließlich - root-on-ZFS, ZFS Boot Environments, Fehlermanagement, - administrative Delegation, Unterstützung für Jails, - &os;-spezifische Dokumentation und Unterstützung im - System-Installationsprogramm. - + + Über 30.000 vorkonfigurierte + Pakete für alle unterstützten Architekturen + und die Ports-Sammlung, die es Benutzern einfach macht, + eigene, angepasste Software zu erstellen. + - - Umfangreiche - Sicherheitsfunktionen, vom System für die - verbindliche Zugriffskontrolle (Mandatory Access Control, - MAC), bis hin zu Capsicum und - Sandbox-Mechanismen. - + + Dokumentation - Zusätzlich zu + diesem Handbuch und Büchern von verschiedenen Autoren, + die Themen von Systemadministration bis hin zu + Kernel-Interna behandeln, gibt es auch die &man.man.1; + Seiten, nicht nur für Daemonen, Dienstprogramme und + Konfigurationsdateien, sondern auch für Kernel-APIs + (Sektion 9) und individuelle Treiber (Sektion 4). + - - Über 30.000 vorkonfigurierte - Pakete für alle unterstützten Architekturen - und die Ports-Sammlung, die es Benutzern einfach macht, - eigene, angepasste Software zu erstellen. - + + Einfache und konsistente Repository-Struktur + und Build-System - &os; benutzt ein einziges + Repository für alle seine Komponenten, sowohl den Kernel + als auch das Basissystem. Dies, zusammen mit einem + einheitlichen und leicht anpassbaren Build-System und + einem gut durchdachten Entwicklungsprozess, macht es + einfach, &os; in die Build-Infrastruktur für Ihr eigenes + Produkt zu integrieren. + - - Dokumentation - Zusätzlich zu - diesem Handbuch und Büchern von verschiedenen Autoren, - die Themen von Systemadministration bis hin zu - Kernel-Interna behandeln, gibt es auch die &man.man.1; - Seiten, nicht nur für Daemonen, Dienstprogramme und - Konfigurationsdateien, sondern auch für - Kernel-APIs (Sektion 9) und - individuelle Treiber (Sektion 4). - + + Der Unix-Philosophie treu bleiben + und Kombinierbarkeit den monolithischen + "all in one"-Daemonen mit hartkodiertem Verhalten + vorziehen. + - - Einfache und konsistente Repository-Struktur - und Build-System - &os; benutzt ein einziges - Repository für alle seine Komponenten, sowohl den Kernel - als auch das Basissystem. Dies, zusammen mit einem - einheitlichen und leicht anpassbaren Build-System und - einem gut durchdachten Entwicklungsprozess, macht es - einfach, &os; in die Build-Infrastruktur für Ihr eigenes - Produkt zu integrieren. - + + Binärkompatibilität + Linux + Binärkompatibilität mit Linux, die es + möglich macht, viele Linux-Binärdateien ohne + Virtualisierung auszuführen. + + - - Der Unix-Philosophie treu bleiben - und Kombinierbarkeit den monolithischen - "all in one"-Daemonen mit hartkodiertem Verhalten - vorziehen. - + &os; basiert auf dem 4.4BSD-Lite + 4.4BSD-Lite + Release der Computer Systems Research + Group (CSRG)Computer Systems Research Group + (CSRG) der Universität von Kalifornien + in Berkeley und führt die namenhafte Tradition der Entwicklung + von BSD-Systemen fort. Zusätzlich zu der herausragenden Arbeit + CSRG hat das &os; Projekt tausende weitere Arbeitsstunden + investiert, um das System zu erweitern, verfeinern und maximale + Leistung und Zuverlässigkeit bei Alltagslast zu bieten. &os; + bietet Leistung und Zuverlässigkeit auf dem Niveau von Open + Source und kommerziellen Angeboten, und kombiniert innovative + Funtionen, die woanders nicht verfübar sind. - - Binärkompatibilität - Linux - Binärkompatibilität mit Linux, die es - möglich macht, viele Linux-Binärdateien ohne - Virtualisierung auszuführen. - - - - &os; basiert auf dem 4.4BSD-Lite- - 4.4BSD-Lite - Release der Computer Systems Research Group - (CSRG) Computer Systems Research Group - (CSRG) - der Universität von Kalifornien in Berkeley und - führt die namenhafte Tradition der Entwicklung von - BSD-Systemen fort. Zusätzlich zu der herausragenden Arbeit - der CSRG hat das &os; Projekt tausende weitere Arbeitsstunden - investiert, um das System zu erweitern, verfeinern und maximale Leistung - und Zuverlässigkeit bei Alltagslast zu bieten. &os; bietet - Leistung und Zuverlässigkeit auf dem Niveau von Open Source - und kommerziellen Angeboten, und kombiniert innovative Funtionen, die - woanders nicht verfübar sind. - + + Was kann FreeBSD? Die Anwendungsmöglichkeiten von &os; werden nur durch Ihre Vorstellungskraft begrenzt. Von Software-Entwicklung bis zu Produktionsautomatisierung, von Lagerverwaltung über From owner-svn-doc-all@freebsd.org Wed Sep 12 00:52:19 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9758010A4349; Wed, 12 Sep 2018 00:52:18 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C46F9237F; Wed, 12 Sep 2018 00:52:18 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 46BD51F730; Wed, 12 Sep 2018 00:52:18 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8C0qI9l091626; Wed, 12 Sep 2018 00:52:18 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8C0qHJB091623; Wed, 12 Sep 2018 00:52:17 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809120052.w8C0qHJB091623@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Wed, 12 Sep 2018 00:52:17 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52247 - in head/pt_BR.ISO8859-1/articles: . rc-scripting X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/articles: . rc-scripting X-SVN-Commit-Revision: 52247 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 00:52:19 -0000 Author: ebrandi Date: Wed Sep 12 00:52:17 2018 New Revision: 52247 URL: https://svnweb.freebsd.org/changeset/doc/52247 Log: pt_BR.ISO8859-1/articles/rc-scripting: New pt_BR translation into .po format - content synchronized with en_US document (rev 44709) - article.xml converted to .po - .po file was translated to pt_BR - .po and .xml file has been set to UTF-8 encoding - information about volunteers who translated and/or revised the document was added to the header of the .po file. - enabled the build of the article into pt_BR.ISO8859-1/articles/Makefile Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/rc-scripting/ head/pt_BR.ISO8859-1/articles/rc-scripting/Makefile (contents, props changed) head/pt_BR.ISO8859-1/articles/rc-scripting/article.xml (contents, props changed) head/pt_BR.ISO8859-1/articles/rc-scripting/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/Makefile Modified: head/pt_BR.ISO8859-1/articles/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile Tue Sep 11 18:40:23 2018 (r52246) +++ head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 12 00:52:17 2018 (r52247) @@ -24,6 +24,7 @@ SUBDIR+= new-users SUBDIR+= port-mentor-guidelines SUBDIR+= pr-guidelines SUBDIR+= problem-reports +SUBDIR+= rc-scripting SUBDIR+= remote-install SUBDIR+= solid-state Added: head/pt_BR.ISO8859-1/articles/rc-scripting/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/rc-scripting/Makefile Wed Sep 12 00:52:17 2018 (r52247) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: RC Scripting + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/rc-scripting/article.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/rc-scripting/article.xml Wed Sep 12 00:52:17 2018 (r52247) @@ -0,0 +1,671 @@ + + +

    + Scripts rc.d práticos no BSD + + + YarTikhiy
    yar@FreeBSD.org
     + + 2005 2006 2012 The FreeBSD Project + + + FreeBSD is a registered trademark of the FreeBSD Foundation. + NetBSD is a registered trademark of the NetBSD Foundation. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the â„¢ or the ® symbol. + + + $FreeBSD$ + + $FreeBSD$ + + + Os iniciantes podem achar difícil relacionar os fatos da documentação formal do framework rc.d do BSD com as tarefas práticas do script rc.d. Neste artigo, consideramos alguns casos típicos de complexidade crescente, vamos mostrar os recursos do rc.d adequados para cada caso e vamos discutir como eles funcionam. Esse exame deve fornecer pontos de referência para um estudo mais aprofundado do design e da aplicação eficiente do rc.d. + +     + + + Introdução + + Historicamente o BSD tinha um script de inicialização monolítico, o /etc/rc. Ele era chamado pelo init 8 no momento da inicialização do sistema e executava todas as tarefas necessárias para a operação multi-usuário: verificação e montagem do sistemas de arquivos, configuração de rede, iniciava daemons e assim por diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os administradores precisavam personalizá-lo. Com poucas exceções, o /etc/rc teve que ser modificado, e os verdadeiros hackers gostaram disso. + + O problema real com a abordagem monolítica era que ela não fornecia nenhum controle sobre os componentes individuais iniciados a partir do /etc/rc. Por exemplo, o /etc/rc não podia reiniciar um único daemon. O administrador do sistema tinha que encontrar o processo daemon manualmente, matá-lo, esperar até que ele realmente finalizasse, então procurar pelas flags no /etc/rc, e finalmente digitar a linha de comando completa para iniciar o daemon novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o serviço de reinicialização consistisse em mais de um daemon ou exigisse ações adicionais. Em poucas palavras, o único script não cumpriu o objetivo dos scripts: tornar a vida do administrador do sistema mais fácil. + + Mais tarde, houve uma tentativa de dividir algumas partes do /etc/rc para iniciar os subsistemas mais importantes separadamente. O exemplo notório foi o /etc/netstart para configurar a rede. Ele permitia acessar a rede a partir do modo single-user, mas não se integrou bem ao processo de inicialização automática porque partes de seu código precisavam intercalar com ações essencialmente não relacionadas à rede. Foi por isso que o /etc/netstart mudou para /etc/rc.network. Este último não era mais um script comum; ele era composto por um emaranhado de funções sh1 chamadas pelo /etc/rc em diferentes estágios da inicialização do sistema. No entanto, a medida que as tarefas de inicialização cresciam variadas e sofisticadas, a abordagem quase modular tornou-se ai nda mais engessada do que o monolítico /etc/rc. + + Sem um framework limpo e bem projetado, os scripts de inicialização tiveram que se curvar para satisfazer as necessidades de desenvolvimento rápido dos sistemas operacionais baseados no BSD. Tornou-se óbvio, finalmente, que mais passos eram necessários no caminho para construção de um sistema rc extensível e customizável. Assim nasceu o BSD rc.d. Seus pais reconhecidos foram o Luke Mewburn e a comunidade do NetBSD. Mais tarde ele foi importado para o FreeBSD. Seu nome se refere à localização dos scripts do sistema para serviços individuais, que é o /etc/rc.d. Em breve, vamos aprender sobre mais componentes do sistema rc.d e vamos ver como os scripts individuais são invocados. + + As idéias básicas por trás do BSD rc.d são modularidade fina e reutilização de código. Modularidade fina significa que cada serviço básico, como um daemon do sistema ou uma tarefa de inicialização primitiva, obtém seu próprio script sh capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar seu status. Uma ação específica é escolhida pelo argumento da linha de comando para o script. O script /etc/rc ainda comanda a inicialização do sistema, mas agora ele simplesmente invoca os scripts menores um por um com o argumento . É fácil executar tarefas de desligamento executando o mesmo conjunto de scripts com o argumento , o que é feito pelo /etc/rc.shutdown. Observe como isso segue de perto o mod o Unix de ter um conjunto de pequenas ferramentas especializadas, cada uma cumprindo sua tarefa da melhor forma possível. Reutilização de código significa que operações comuns são implementadas como funções sh1 e coletadas em /etc/rc.subr . Agora, um script típico pode conter apenas algumas linhas de código sh1 . Finalmente, uma parte importante do framework do rc.d é rcorder 8 , o qual ajuda o /etc/rc a executar os pequenos scripts ordenadamente em relação às dependências entre eles. Ele também pode ajudar o /etc/rc.shutdown, porque a ordem apropriada para a sequência de encerramento é oposta à da inicialização. + + O design do BSD rc.d é descrito no artigo original de Luke Mewburn, e os componentes do rc.d são documentados em grande detalhe nas respectivas páginas de manual. No entanto, pode não parecer óbvio para um novato em rc.d como amarrar os inúmeros pedaços juntos para criar um script bem estilizado para uma tarefa específica. Portanto, este artigo tentará uma abordagem diferente para descrever o rc.d. Ele mostrará quais recursos devem ser usados em vários casos típicos e por quê. Note que este não é um documento explicativo porque nosso objetivo não é fornecer receitas prontas, mas mostrar algumas entradas fáceis no domínio do rc.d. Nem este artigo é um substituto para as páginas de manual relevantes. Não hesite em consultá-los para obter uma documentação mais formal e completa ao ler est e artigo. + + Existem pré-requisitos para entender este artigo. Primeiro de tudo, você deve estar familiarizado com a linguagem de script sh1 para poder dominar o rc.d. Além disso, você deve saber como o sistema executa as tarefas de inicialização e encerramento do userland, o que está descrito em rc8. + + Este artigo foca no branch rc.d do FreeBSD. No entanto, ele também pode ser útil para os desenvolvedores do NetBSD, porque os dois branchs rc.d do BSD não apenas compartilham o mesmo design, mas também permanecem similares em seus aspectos visíveis aos autores do script. + + + + Esboçando a tarefa + + Um pouco de consideração antes de iniciar o $EDITOR não irá prejudicar. Para escrever um script rc.d corretamente customizado para um serviço do sistema, devemos poder responder as seguintes questões primeiro: + + + + O serviço é obrigatório ou opcional? + + + + O script servirá um único programa, por exemplo, um daemon, ou realizará ações mais complexas? + + + + De quais outros serviços nosso serviço dependerá e vice-versa? + + + + A partir dos exemplos que se seguem, veremos o porque é importante conhecer as respostas a essas perguntas. + + + + Um script fictício + + O script a seguir apenas emite uma mensagem toda vez que o sistema é inicializado: + + + #!/bin/sh + +. /etc/rc.subr + +name="dummy" +start_cmd="${name}_start" +stop_cmd=":" + +dummy_start() +{ + echo "Nothing started." +} + +load_rc_config $name +run_rc_command "$1" + + + Os pontos a serem observadas são: + + + + Um script interpretado deve começar com a linha mágica shebang. Essa linha especifica o programa interpretador para o script. Devido a linha shebang, o script pode ser invocado exatamente como um programa binário, desde que tenha o bit de execução definido. (Veja chmod1.) Por exemplo, um administrador do sistema pode executar nosso script manualmente, a partir da linha de comando: + + # /etc/rc.d/dummy start + + + Para ser adequadamente gerenciado pelo framework do rc.d, seus scripts precisam ser escritos na linguagem sh1. Se você tiver um serviço ou port que use um utilitário de controle binário ou uma rotina de inicialização escrita em outra linguagem, instale este elemento em /usr/sbin (para o sistema) ou em /usr/local/sbin (para um port) e invoque-o por meio de um script sh1 no diretório apropriado do rc.d. + + + + Caso você queira aprender os detalhes do porque os scripts rc.d devem ser escritos na linguagem sh1, veja como o /etc/rc invoca-os por meio de run_rc_script, e então estude a implementação de run_rc_script em /etc/rc. subr. + + + + + Em /etc/rc.subr, várias funções sh1 estão definidas para serem utilizadas por um script rc.d. As funções estão documentadas em rc.subr 8. Embora seja teoricamente possível escrever um script rc.d sem usar o rc.subr8, as suas funções são extremamente úteis e tornam o trabalho mais fácil. Portanto, não é de surpreender que todos recorram a scripts rc.subr8 em rc.d. Nós não vamos ser uma exceção. + + Um script rc.d deve incluir o /etc/rc.subr (isto por ser feito usando o comando .) antes que ele chame as funções do rc.subr8 para que o sh1 tenha a oportunidade para aprender as funções. O estilo preferido é incluir o /etc/rc.subr antes de tudo. + + + Algumas funções úteis relacionadas a rede são fornecidas por outro arquivo include, o /etc/network.subr. + + + + + A variável obrigatória name especifica o nome do nosso script. Ela é exigida pelo rc.subr8. Ou seja, cada script rc.d deve definir a variável name antes de chamar funções do rc.subr8. + + Agora é o momento certo para escolher um nome exclusivo para o nosso script de uma vez por todas. Vamos usá-lo em vários lugares enquanto desenvolvemos o script. Para começar, também vamos dar o mesmo nome ao arquivo de script. + + + O estilo atual do script rc.d é incluir valores atribuídos as variáveis entre aspas duplas. Tenha em mente que é apenas um problema de estilo que nem sempre pode ser aplicável. Você pode omitir com segurança as aspas das palavras simples sem os metacaracteres do sh1 nelas, enquanto em certos casos você precisará de aspas simples para evitar qualquer interpretação do valor pelo sh1. Um programador deve ser capaz de dizer a sintaxe da linguagem a partir das convenções de estilo e bem como de usá-las sabiamente. + + + + + A idéia principal por trás do rc.subr8 é que um script rc.d fornece manipuladores, ou métodos, para o rc.subr8 invocar. Em particular, , e outros argumentos para um script rc.d são tratados desta maneira. Um método é uma expressão sh1 armazenada em uma variável denominada argument_cmd, no qual argument corresponde ao que pode ser especificado na linha de comando do script. Vamos ver mais adiante como o rc.subr8 fornece métodos default para os argumentos padrão. + + + Para tornar o código em rc.d mais uniforme, é comum usar ${name} onde for apropriado. Assim, várias linhas podem ser copiadas de um script para outro. + + + + + Devemos ter em mente que o rc.subr8 fornece métodos default para os argumentos padrões. Consequentemente, devemos sobrescrever um método default com uma expressão no-op sh se desejarmos que ele não faça nada. + + + + O corpo de um método sofisticado pode ser implementado como uma função. É uma boa ideia tornar o nome da função significativo. + + + É altamente recomendado adicionar o prefixo ${name} aos nomes de todas as funções definidas em nosso script, para que eles nunca entrem em conflito com as funções do rc.subr8 ou outro arquivo de inclusão comum. + + + + + Essa chamada ao rc.subr8 carrega as variáveis do rc.conf5. Nosso script não faz uso delas ainda, mas ainda assim é recomendado carregar o rc.conf5 pois podem haver variáveis rc.conf5 controlando o rc.subr8 propriamente dito. + + + + Geralmente este é o último comando em um script rc.d. Ele invoca o maquinário rc.subr8 para executar a ação solicitada usando as variáveis e métodos que nosso script forneceu. + + + + + + Um script fictício configurável + + Agora vamos adicionar alguns controles ao nosso script fictício. Como você deve saber, os scripts rc.d são controlados pelo rc.conf5. Felizmente, o rc.subr8 esconde todas as complicações de nós. O script a seguir usa o rc.conf5 via rc.subr8 para ver se ele está habilitado em primeiro lugar, e buscar uma mensagem para mostrar no momento da inicialização. Estas duas tarefas são de fato independentes. Por um lado, um script rc.d pode apenas suportar a ativação e desativação de seu serviço. Por outro lado, um script rc.d obrigatório pode ter variáveis de configuração. Nà ³s vamos fazer as duas coisas no mesmo script: + + + #!/bin/sh + +. /etc/rc.subr + +name=dummy +rcvar=dummy_enable + +start_cmd="${name}_start" +stop_cmd=":" + +load_rc_config $name +: ${dummy_enable:=no} +: ${dummy_msg="Nothing started."} + +dummy_start() +{ + echo "$dummy_msg" +} + +run_rc_command "$1" + + + O que mudou neste exemplo? + + + + A variável rcvar especifica o nome da variável do botão ON/OFF. + + + + Agora o load_rc_config é invocado anteriormente no script, antes que qualquer variável do rc.conf5 seja acessada. + + + Ao examinar os scripts rc.d, tenha em mente que o sh1 adia a avaliação de expressões em uma função até que a função seja chamada. Portanto, não é um erro invocar load_rc_config tão tarde quanto antes do run_rc_comman e ainda acessar as variáveis do rc.conf5 a partir do método das funções exportadas para o run_rc_command. Isto ocorre porque as funções do método devem ser chamadas por run_rc_command, que é chamado após o load_rc_config. + + + + + Um aviso será emitido pelo run_rc_command se o próprio rcvar estiver definido, mas a variável de knob indicada não estiver definida. Se o seu script rc.d for para o sistema base, você deve adicionar uma configuração padrão para o knob no /etc/defaults/rc.conf e documentá-lo em rc.conf5. Caso contrário, será o seu script que deverá fornecer uma configuração padrão para o knob. A abordagem canônica para o último caso é mostrada no exemplo. + + + Você pode fazer o rc.subr8 agir como se o knob fosse definido como ON, independentemente da sua configuração atual, prefixando o argumento para o script com one ou force, como em ou . Tenha em mente que o force tem outros efeitos perigosos que mencionaremos abaixo, enquanto one apenas sobrescreve o knob ON/OFF. Por exemplo, suponha que dummy_enable seja OFF. O comando a seguir executará o método apesar da configuração: + + # /etc/rc.d/dummy onestart + + + + + Agora, a mensagem a ser mostrada no momento da inicialização não é mais codificada no script. Ela é especificada por uma variável do rc.conf5 chamada dummy_msg. Este é um exemplo trivial de como as variáveis do rc.conf 5 podem controlar um script rc.d. + + + Os nomes de todas as variáveis do rc.conf5 usadas exclusivamente pelo nosso script devem possuir o mesmo prefixo: $ {name} _. Por exemplo: dummy_mode, dummy_state_file, e assim por diante. + + + + Embora seja possível usar um nome mais curto internamente, por exemplo, apenas msg, adicionar o prefixo exclusivo ${name}_ a todos os nomes globais introduzidos pelo nosso script nos salvará de possíveis colisões com o nome das funções existentes no rc.subr8. + + Como regra, os scripts rc.d do sistema base não precisam fornecer valores padrões para as suas variáveis rc.conf 5 porque os padrões devem ser definidos em /etc/defaults/rc.conf. Por outro lado, os scripts rc.d para os ports devem fornecer os valores padrões, conforme mostrado no exemplo. + + + + + Aqui usamos dummy_msg para realmente controlar nosso script, ou seja, para emitir uma mensagem variável. O uso de uma função de shell é um exagero aqui, já que ele só executa um único comando; uma alternativa igualmente válida seria: + + start_cmd="echo \"$dummy_msg\"" + + + + + + Inicialização e desligamento de um daemon simples + + Dissemos anteriormente que o rc.subr8 poderia fornecer métodos padrão. Obviamente, estes padrões não podem ser muito gerais. Eles são adequados para o caso comum de iniciar e encerrar um programa daemon simples. Vamos supor agora que precisamos escrever um script rc.d para um daemon chamado mumbled. Aqui está: + + + #!/bin/sh + +. /etc/rc.subr + +name=mumbled +rcvar=mumbled_enable + +command="/usr/sbin/${name}" + +load_rc_config $name +run_rc_command "$1" + + + Agradavelmente simples, não é? Vamos examinar nosso pequeno script. A única coisa nova a observar é o seguinte: + + + + A variável command é significativa para o rc.subr8. Se estiver definido, o rc.subr 8 agirá de acordo com o cenário de servir um daemon convencional. Em particular, os métodos padrão serão fornecidos para tais argumentos: , , , , e . + + O daemon será iniciado executando $command com os sinalizadores de linha de comando especificados por $mumbled_flags. Assim, todos os dados de entrada para o método padrão estão disponíveis nas variáveis configuradas pelo nosso script. Ao contrário do , outros métodos podem requerer informações adicionais sobre o processo iniciado. Por exemplo, deve conhecer o PID do processo para terminá-lo. No presente caso, rc.subr8 varrerá a lista de todos os processos, procurando por um processo com seu nome igual a $procname. Esta última é outra variável de significado para rc.subr8, e seu valor é padronizado para command. Em outras palavras, quando definimos o command , procname é efetivamente definido para o mesmo valor. Isso permite que nosso script mate o daemon e verifique se ele está sendo executado em primeiro lugar. + + + Alguns programas são, na verdade, scripts executáveis. O sistema executa esse script iniciando seu interpretador e passando o nome do script para ele como um argumento de linha de comando. Isso é refletido na lista de processos, que podem confundir o rc.subr8. Você também deve definir o command_interpreter para permitir que o rc.subr8 saiba o nome real do processo se o $command é um script. + + Para cada script rc.d, existe uma variável rc.conf que tem precedência sobre command. Seu nome é construído da seguinte forma: ${name}_program, onde name é a variável obrigatória que discutimos anteriormente. Por exemplo, neste caso, será mumbled_program . É rc.subr8que organiza${name}_program para substituir o comando. + + Obviamente, o sh1 permitirá que você defina ${name}_program a partir do rc.conf 5 ou o próprio script, mesmo que o command esteja indefinido. Nesse caso, as propriedades especiais de ${name}_program são perdidas e se tornam uma variável comum que seu script pode usar para seus próprios propósitos. No entanto, o uso exclusivo de ${name}_program é desencorajado porque usá-lo junto com o command tornou-se um idioma na escrita de scripts rc.d. + + + Para obter informações mais detalhadas sobre métodos padrões, consulte rc.subr8. + + + + + + Inicialização e desligamento de um daemon avançado + + Vamos adicionar um pouco de carne aos ossos do script anterior e torná-lo mais complexo e cheio de funcionalidades. Os métodos padrões podem fazer um bom trabalho para nós, mas podemos precisar ajustar alguns dos seus aspectos. Agora vamos aprender como ajustar os métodos padrões para as nossas necessidades. + + + #!/bin/sh + +. /etc/rc.subr + +name=mumbled +rcvar=mumbled_enable + +command="/usr/sbin/${name}" +command_args="mock arguments > /dev/null 2>&1" + +pidfile="/var/run/${name}.pid" + +required_files="/etc/${name}.conf /usr/share/misc/${name}.rules" + +sig_reload="USR1" + +start_precmd="${name}_prestart" +stop_postcmd="echo Bye-bye" + +extra_commands="reload plugh xyzzy" + +plugh_cmd="mumbled_plugh" +xyzzy_cmd="echo 'Nothing happens.'" + +mumbled_prestart() +{ + if checkyesno mumbled_smart; then + rc_flags="-o smart ${rc_flags}" + fi + case "$mumbled_mode" in + foo) + rc_flags="-frotz ${rc_flags}" + ;; + bar) + rc_flags="-baz ${rc_flags}" + ;; + *) + warn "Invalid value for mumbled_mode" + return 1 + ;; + esac + run_rc_command xyzzy + return 0 +} + +mumbled_plugh() +{ + echo 'A hollow voice says "plugh".' +} + +load_rc_config $name +run_rc_command "$1" + + + + + Argumentos adicionais para $command podem ser passados em command_args. Eles serão adicionados a linha de comando após $mumbled_flags. Como a linha de comando final é passada para eval para sua execução real, os redirecionamentos de entrada e saída podem ser especificados em command_args. + + + Nunca inclua opções tracejadas, como ou , em command_args. O conteúdo de command_args aparecerá no final da linha de comando final, portanto é provável que eles sigam os argumentos presentes em ${name}_flags; mas a maioria dos comandos não reconhecerá opções tracejadas após argumentos comuns. Uma maneira melhor de passar opções adicionais para $command é adicioná-las ao início de ${name}_flags . Outra maneira é modificar rc_flags como mostrado posteriormente . + + + + + Um daemon de boas maneiras deve criar um pidfile para que seu processo possa ser encontrado com mais facilidade e confiabilidade. A variável pidfile, se configurada, informa ao rc.subr8 onde pode encontrar o pidfile para seus métodos padrão possam usar. + + + De fato, o rc.subr 8 também usará o pidfile para ver se o daemon já está em execução antes de iniciá-lo. Esta verificação pode ser ignorada usando o argumento . + + + + + Se o daemon não puder ser executado a menos que existam certos arquivos, apenas liste-os em required_files, e rc.subr8 irá verificar se esses arquivos existem antes de iniciar o daemon. Também existem required_dirs e required_vars para diretórios e variáveis de ambiente, respectivamente. Todos eles são descritos em detalhes em rc.subr8. + + + O método padrão de rc.subr8 pode ser forçado a ignorar as verificações de pré-requisitos usando como o argumento para o script. + + + + + Podemos personalizar sinais para enviar para o daemon caso eles sejam diferentes dos mais conhecidos. Em particular, sig_reload especifica o sinal que faz o daemon recarregar sua configuração; é SIGHUP por padrão. Outro sinal é enviado para parar o processo do daemon; o padrão é SIGTERM, mas isso pode ser alterado definindo sig_stop apropriadamente. + + + Os nomes dos sinais devem ser especificados para o rc.subr 8 sem o prefixo SIG, como é mostrado no exemplo. A versão do FreeBSD do kill1 pode reconhecer o prefixo SIG, mas as versões de outros tipos de sistema operacional não. + + + + + Realizar tarefas adicionais antes ou depois dos métodos padrão é fácil. Para cada argumento de comando suportado pelo nosso script, podemos definir o argumento _precmd e _postcmd. Esses comandos no sh 1 são invocados antes e depois do respectivo método, como é evidente em seus nomes. + + + Sobrescrever um método padrão com um argumento _cmd personalizado ainda não nos impede de fazer uso do argumento _precmd ou argumento _postcmd se precisarmos. Em particular, o primeiro é bom para verificar condições personalizadas e sofisticadas que devem ser atendidas antes de executar o comando em si. Usar o argumento _precmd junto com o argumento _cmd nos permite separar logicamente as verificações da ação. + + Não se esqueça de que você pode amontoar qualquer expressão válida do sh1 nos métodos, pré e pós-comandos definidos por você. Apenas invocar uma função que faz com que o trabalho real seja um bom estilo na maioria dos casos, mas nunca deixe o estilo limitar sua compreensão do que está acontecendo por trás da cortina. + + + + + Se quisermos implementar argumentos customizados, que também podem ser considerados como comandos para o nosso script, precisamos listá-los em extra_commands e fornecer métodos para manipulá-los. + + + O comando é especial. Por um lado, tem um método predefinido em rc.subr8. Por outro lado, não é oferecido por padrão. A razão é que nem todos os daemons usam o mesmo mecanismo de recarga e alguns não têm nada para recarregar. Portanto, precisamos solicitar explicitamente que a funcionalidade incorporada seja fornecida. Podemos fazer isso via extra_commands. + + O que obtemos do método padrão para ? Muitas vezes, os daemons recarregam sua configuração na recepção de um sinal - normalmente, SIGHUP. Portanto, o rc.subr 8 tenta recarregar o daemon enviando um sinal para ele. O sinal é predefinido para SIGHUP, mas pode ser personalizado via sig_reload, caso necessário. + + + + + Nosso script suporta dois comandos não padrão, e . Nós os vimos listados em extra_commands, e agora é hora de fornecer métodos para eles. O método para é apenas embutido, enquanto que para é implementado como a função mumbled_plugh. + + Comandos não padrão não são chamados durante a inicialização ou o desligamento. Geralmente eles são para a conveniência do administrador do sistema. Eles também podem ser usados de outros subsistemas, por exemplo, devd 8 se especificado em devd.conf5 . + + A lista completa de comandos disponíveis pode ser encontrada na linha de uso impressa por rc.subr8 quando o script é invocado sem argumentos. Por exemplo, aqui está a linha de uso do script em estudo: + + # /etc/rc.d/mumbled +Uso: /etc/rc.d/mumbled [fast|force|one](start|stop|restart|rcvar|reload|plugh|xyzzy|status|poll) + + + + Um script pode invocar seus próprios comandos padrão ou não padrão, se necessário. Isto pode parecer semelhante as funções de chamada, mas sabemos que comandos e funções de shell nem sempre são a mesma coisa. Por exemplo, xyzzy não é implementado como uma função aqui. Além disso, pode haver um pré-comando e um pós-comando, que devem ser chamados ordenadamente. Portanto, a maneira correta de um script executar seu próprio comando é por meio de rc.subr8, conforme mostrado no exemplo. + + + + Uma função útil chamada checkyesno é fornecida por rc.subr8 . Ele usa um nome de variável como argumento e retorna um código de saída zero se, e somente se, a variável estiver configurada como YES, ou TRUE, ou ON, ou 1, sem distinção entre maiúsculas e minúsculas; um código de saída diferente de zero é retornado de outra forma. No último caso, a função testa a variável como sendo definida como NO,FALSE,OFFou0 insensível a maiúsculas e minúsculas; imprime uma mensagem de aviso se a variável contiver qualquer outra coisa, ou seja, lixo. + + Tenha em mente que para o sh1 um código de saída zero significa verdadeiro e um código de saída diferente de zero significa falso. + + + A função checkyesno recebe um nome da variável. Não passe o valor expandido de uma variável para ele; não funcionará como esperado. + + O uso correto de checkyesno é: + + if checkyesno mumbled_enable; then + foo +fi + + Pelo contrário, chamar checkyesno como mostrado abaixo não funcionará - pelo menos não como esperado: + + if checkyesno "${mumbled_enable}"; then + foo +fi + + + + + Podemos afetar os sinalizadores a serem passados para $command modificando rc_flags em $start_precmd. + + + + Em certos casos, podemos precisar emitir uma mensagem importante que também deve ser enviada para o syslog. Isto pode ser feito facilmente com as seguintes funções rc.subr 8: debug, info, warn e err. A última função, em seguida, sai do script com o código especificado. + + + + Os códigos de saída dos métodos e seus pré-comandos não são apenas ignorados por padrão. Se o argumento _precmd retornar um código de saída diferente de zero, o método principal não será executado. Por sua vez, o argumento_postcmd não será invocado a menos que o método principal retorne um código de saída zero. + + + No entanto, o rc.subr 8 pode ser instruído a partir da linha de comando para ignorar esses códigos de saída e invocar todos os comandos, prefixando um argumento com force, como em . + + + + + + + Conectando um script ao framework rc.d + + Depois que um script foi escrito, ele precisa ser integrado em rc.d>. O passo crucial é instalar o script em /etc/rc.d (para o sistema base) ou /usr/local/etc/rc.d (para ports). Ambos <bsd.prog.mk > e < bsd.port.mk > fornecer ganchos convenientes para isso, e geralmente você não precisa se preocupar com a propriedade e o modo adequado. Os scripts do sistema devem ser instalados a partir do src /etc/rc.d através do Makefile encontrado lá. Os scripts de porta podem ser instalados usando USE_RC_SUBR conforme descrito em no Manual do Porter. + + No entanto, devemos considerar antecipadamente o local do nosso script na sequência de inicialização do sistema. O serviço manipulado pelo nosso script provavelmente depende de outros serviços. Por exemplo, um daemon de rede não pode funcionar sem as interfaces de rede e o roteamento em funcionamento. Mesmo que um serviço pareça não exigir nada, dificilmente pode ser iniciado antes que os sistemas de arquivos básicos tenham sido verificados e montados. + + Nós já mencionamos o rcorder8. Agora é hora de dar uma olhada de perto. Em poucas palavras, o rcorder 8 pega um conjunto de arquivos, examina seu conteúdo e imprime uma lista ordenada por dependência de arquivos do conjunto para stdout. O objetivo é manter as informações de dependência dentro dos arquivos para que cada arquivo possa falar por si só. Um arquivo pode especificar as seguintes informações: + + + + os nomes das condições (o que significa serviços para nós) que ele fornece; + + + + os nomes das condições que ele requer; + + + + os nomes das condições deste arquivo devem ser executados antes; + + + + palavras-chave adicionais que podem ser usadas para selecionar um subconjunto de todo o conjunto de arquivos ( rcorder8 podem ser instruídos através de opções para incluir ou omitir os arquivos com determinadas palavras-chave listadas.) + + + + Não é surpresa que rcorder8 possa manipular apenas arquivos de texto com uma sintaxe próxima a de sh1. Ou seja, linhas especiais compreendidas por rcorder8 se parecem com comentários sh1. A sintaxe de tais linhas especiais é bastante rígida para simplificar seu processamento. Veja rcorder8 para detalhes. + + Além de usar linhas especiais do rcorder8, um script pode insistir em sua dependência de outro serviço apenas iniciando-o forçadamente. Isso pode ser necessário quando o outro serviço é opcional e não será iniciado automaticamente porque o administrador do sistema o desativou por engano no rc.conf5. + + Com este conhecimento geral em mente, vamos considerar o simples script daemon aprimorado com coisas de dependência: + + + #!/bin/sh + +# PROVIDE: mumbled oldmumble +# REQUIRE: DAEMON cleanvar frotz +# BEFORE: LOGIN +# KEYWORD: nojail shutdown + +. /etc/rc.subr + +name=mumbled +rcvar=mumbled_enable + +command="/usr/sbin/${name}" +start_precmd="${name}_prestart" + +mumbled_prestart() +{ + if ! checkyesno frotz_enable && \ + ! /etc/rc.d/frotz forcestatus 1>/dev/null 2>&1; then + force_depend frotz || return 1 + fi + return 0 +} + +load_rc_config $name +run_rc_command "$1" + + + Como antes, a análise detalhada segue: + + + + Esta linha declara os nomes das condições que nosso script fornece. Agora, outros scripts podem registrar uma dependência em nosso script por estes nomes. + + + Geralmente, um script especifica uma única condição fornecida. No entanto, nada nos impede de listar várias condições, por exemplo, por razões de compatibilidade. + + Em qualquer caso, o nome da condição principal, ou a única, PROVIDE: deve ser o mesmo que ${name}. + + + + + Portanto, nosso script indica quais condições são fornecidas por outros scripts dos quais depende. De acordo com as linhas, nosso script pede ao rcorder 8 para colocá-lo após o(s) script(s) fornecendo DAEMON e cleanvar, mas antes disso prover LOGIN. + + + A linha BEFORE: não deve ser abusada para contornar uma lista de dependências incompleta no outro script. O caso apropriado para usar o BEFORE: é quando o outro script não se importa com o nosso, mas nosso script pode fazer sua tarefa melhor se for executado antes do outro. Um típico exemplo da vida real são as interfaces de rede versus o firewall: embora as interfaces não dependam do firewall em realizar seu trabalho, a segurança do sistema se beneficiará do firewall estar pronto antes que haja qualquer tráfego de rede. + + Além das condições correspondentes a um único serviço, existem meta-condições e seus scripts placeholder usados para garantir que determinados grupos de operações sejam executados antes dos outros. Estes são denotados pelos nomes UPPERCASE. Sua lista e finalidades podem ser encontradas em rc8. + + Tenha em mente que colocar um nome de serviço na linha REQUIRE: não garante que o serviço estará realmente em execução no momento em que nosso script for iniciado. O serviço necessário pode falhar ao iniciar ou simplesmente ser desativado em rc.conf5 . Obviamente, o rcorder 8 não pode controlar tais detalhes, e o rc8 também não fará isso. Consequentemente, o aplicativo iniciado por nosso script deve ser capaz de lidar com quaisquer serviços necessários indisponíveis. Em certos casos, podemos ajudá-lo conforme discutido abaixo. + + + + + Como lembramos do texto acima, as palavras-chave do rcorder 8 podem ser usadas para selecionar ou deixar alguns scripts. Ou seja, qualquer consumidor rcorder 8 pode especificar através das opções e que as palavras-chave estão na keep list e na skip list, respectivamente. De todos os arquivos a serem classificados, o rcorder 8 selecionará apenas aqueles que tiverem uma palavra-chave da lista de manutenção (a menos que vazia) e não uma palavra-chave da lista de itens ignorados. + + No FreeBSD, o rcorder8 é usado por /etc/rc e /etc/rc.shutdown. Esses dois scripts definem a lista padrão de palavras-chave do rc.d do FreeBSD e seus significados da seguinte forma: + + + + nojail + + + O serviço não é para o ambiente jail8 . Os procedimentos automáticos de inicialização e encerramento ignoram o script se estiverem executando dentro de uma jail. + + + + + nostart + + + O serviço deve ser iniciado manualmente ou não iniciado. O procedimento de inicialização automática irá ignorar o script. Em conjunto com a palavra-chave shutdown, isso pode ser usado para escrever scripts que fazem algo apenas no desligamento do sistema. + + + + + shutdown + + + Esta palavra-chave deve ser listada explicitamente se o serviço precisar ser interrompido antes do desligamento do sistema. + + + Quando o sistema for desligado, o /etc/rc.shutdown será executado. Ele assume que a maioria dos scripts rc.d não tem nada a fazer naquele momento. Portanto, /etc/rc.shutdown invoca seletivamente os scripts rc.d com a palavra-chave shutdown, efetivamente ignorando o restante dos scripts. Para um desligamento ainda mais rápido, o /etc/rc.shutdown passa o comando para os scripts que executa, para que eles ignorem as verificações preliminares, por exemplo, a verificação do pidfile. Como os serviços dependentes devem ser parados antes de seus pré-requisitos, /etc/rc.shutdown executa os scripts na ordem de dependência inversa. + + Se estiver escrevendo um script rc.d real, você deve considerar se é relevante no momento do desligamento do sistema. Por exemplo, se o seu script funcionar apenas em resposta ao comando , não será necessário incluir essa palavra-chave. No entanto, se o seu script gerenciar um serviço, provavelmente será uma boa ideia pará-lo antes que o sistema prossiga para o estágio final de sua seqüência de desligamento descrita em halt8. Em particular, um serviço deve ser interrompido explicitamente se precisar de tempo considerável ou ações especiais para encerrar de forma limpa. Um exemplo típico de tal serviço é um mecanismo de banco de dados. + + + + + + + + Para começar, force_depend deve ser usado com muito cuidado. Geralmente é melhor revisar a hierarquia de variáveis de configuração para seus scripts rc. se eles forem interdependentes. + + Se você ainda não pode fazer sem force_depend, o exemplo oferece uma expressão de como invocá-lo condicionalmente. No exemplo, nosso daemon mumbled requer que outro, frotz, seja iniciado antecipadamente. No entanto, frotz é opcional também; e rcorder8 não sabe nada sobre esses detalhes. Felizmente, nosso script tem acesso a todas as variáveis rc.conf5. Se frotz_enable estiver como true, esperamos pelo melhor e dependemos de rc.d para iniciar frotz. Caso contrário, nós forçadamente verificaremos o status de frotz. Finalmente, impomos nossa dependência ao frotz se ele não estiver sendo executado. Uma mensagem de aviso será emitida po r force_depend porque ele deve ser chamado apenas se um erro de configuração for detectado. + + + + + + Dando mais flexibilidade a um script rc.d + + Quando chamado durante a inicialização ou desligamento, um script rc.d deve agir em todo o subsistema pelo qual é responsável. Por exemplo, /etc/rc.d/netif deve iniciar ou parar todas as interfaces de rede descritas por rc.conf5. Qualquer tarefa pode ser indicada exclusivamente por um único argumento de comando, como ou . Entre a inicialização e o desligamento, os scripts rc.d ajudam o administrador a controlar o sistema em execução, e é quando surge a necessidade de mais flexibilidade e precisão. Por exemplo, o administrador pode querer adicionar as configurações de uma nova interface de rede ao rc.conf 5 e então iniciá-lo sem interferir o funcionamento das interfaces existentes. Da próx ima vez, o administrador pode precisar desligar uma única interface de rede. No espírito da linha de comando, o respectivo script rc.d solicita um argumento extra, o nome da interface. + + Felizmente, rc.subr8 permite passar qualquer número de argumentos para os métodos do script (dentro dos limites do sistema). Devido a isso, as alterações no próprio script podem ser mínimas. + + Como o rc.subr 8 pode obter acesso aos argumentos de linha de comando extra. Deveria pegá-los diretamente? Não por qualquer meio. Primeiro, uma função sh1 não tem acesso aos parâmetros posicionais de seu chamador, mas o rc.subr 8 é apenas uma despedida de tais funções. Em segundo lugar, a boa maneira de rc.d determina que é para o script principal decidir quais argumentos devem ser passados para seus métodos. + + Portanto, a abordagem adotada por rc.subr8 é a seguinte: run_rc_command transmite todos os seus argumentos, mas o primeiro um para o respectivo método na íntegra. O primeiro, omitido, argumento é o nome do próprio método: ,, etc. Ele será deslocado por run_rc_command, então o que é $2 na linha de comando original será apresentado como $1 ao método, e assim por diante. + + Para ilustrar essa oportunidade, vamos modificar o script fictício primitivo para que suas mensagens dependam dos argumentos adicionais fornecidos. Aqui vamos nós: + + + #!/bin/sh + +. /etc/rc.subr + +name="dummy" +start_cmd="${name}_start" +stop_cmd=":" +kiss_cmd="${name}_kiss" +extra_commands="kiss" + +dummy_start() +{ + if [ $# -gt 0 ]; then + echo "Greeting message: $*" + else + echo "Nothing started." + fi +} + +dummy_kiss() +{ + echo -n "A ghost gives you a kiss" + if [ $# -gt 0 ]; then + echo -n " and whispers: $*" + fi + case "$*" in + *[.!?]) + echo + ;; + *) + echo . + ;; + esac +} + +load_rc_config $name +run_rc_command "$@" + + + Quais mudanças essenciais podemos notar no script? + + + + Todos os argumentos digitados após podem terminar como parâmetros posicionais para o respectivo método. Podemos usá-los de qualquer maneira de acordo com nossa tarefa, habilidades e fantasia. No exemplo atual, apenas passamos todos eles para echo 1 como uma cadeia na linha seguinte - note $* entre aspas duplas. Aqui está como o script pode ser chamado agora: + + # /etc/rc.d/dummy start +Nothing started. +# /etc/rc.d/dummy start Hello world! +Greeting message: Hello world! + + + + O mesmo se aplica a qualquer método que nosso script forneça, não apenas a um método padrão. Nós adicionamos um método customizado chamado , e ele pode tirar proveito dos argumentos extras da mesma forma que o tira. Por exemplo: + + # /etc/rc.d/dummy kiss +A ghost gives you a kiss. +# /etc/rc.d/dummy kiss Once I was Etaoin Shrdlu... +A ghost gives you a kiss and whispers: Once I was Etaoin Shrdlu... + + + + Se quisermos apenas passar todos os argumentos extras para qualquer método, podemos simplesmente substituir "$@" por "$ 1" na última linha do nosso script, onde invocamos o run_rc_command. + + + Um programador sh1 deve entender a diferença sutil entre $* e $@ como as formas de designar todos os parâmetros posicionais. Para sua discussão aprofundada, consulte um bom manual sobre programação de scripts sh1. Não use estas expressões até que você as compreenda completamente, porque o uso incorreto delas resultará em scripts inseguros e contendo bugs. + + + + Atualmente, o run_rc_command pode ter um bug que o impede de manter os limites originais entre os argumentos. Ou seja, argumentos com espaços em branco incorporados podem não ser processados corretamente. O bug deriva do uso inadequado de $*. + + + + + + + Leitura adicional + + O artigo original de Luke Mewburn oferece uma visão geral do rc.d e o raciocínio detalhado que o levou a suas decisões de design. Ele fornece informações sobre toda o framework do rc.d e o seu lugar em um moderno sistema operacional BSD. + + As páginas de manual rc 8 , rc.subr8 e rcorder 8 documentam os componentes do rc.d com grande detalhe. Você não pode usar totalmente o poder do rc.d sem estudar as páginas de manual e se referir a elas enquanto escreve seus próprios scripts. + + A sua principal fonte de inspiração são os exemplos da vida real, existentes em no /etc/rc.d de um sistema vivo. Seu conteúdo é fácil e agradável de ler, porque a maioria dos cantos ásperos estão escondidos fundo no rc.subr8. Tenha em mente que os scripts /etc/rc.d não foram escritos por anjos, então eles podem sofrer de bugs e decisões sub-ótimas de design. Agora você pode melhorá-los! + +
    Added: head/pt_BR.ISO8859-1/articles/rc-scripting/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/rc-scripting/pt_BR.po Wed Sep 12 00:52:17 2018 (r52247) @@ -0,0 +1,2732 @@ +# $FreeBSD$ +# André Franciosi , 2018. #zanata +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Lucas Andrade , 2018. #zanata +# Mauro Risonho de Paula Assumpção , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-12 00:45+0000\n" +"PO-Revision-Date: 2018-09-11 11:25+0000\n" +"Last-Translator: André Franciosi \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Lucas Andrade, slucasandrade@protonmail.ch, 2018\n" +"Mauro Risonho de Paula Assumpção, mauro.risonho@gmail.com, 2018\n" +"André Franciosi, andre@franciosi.org, 2018\n" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:4 +msgid "Practical rc.d scripting in BSD" +msgstr "Scripts rc.d práticos no BSD" + +#. (itstool) path: affiliation/address +#: article.translate.xml:8 +#, no-wrap +msgid "yar@FreeBSD.org" +msgstr "yar@FreeBSD.org" + +#. (itstool) path: info/author +#: article.translate.xml:7 +msgid "" +"YarTikhiy <_:address-1/> " +msgstr "" +"YarTikhiy <_:address-1/> " + +#. (itstool) path: info/copyright +#: article.translate.xml:11 +msgid "" +"2005 2006 2012 The FreeBSD " +"Project" +msgstr "" +"2005 2006 2012 The FreeBSD " +"Project" + +#. (itstool) path: legalnotice/para +#: article.translate.xml:20 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:22 +msgid "NetBSD is a registered trademark of the NetBSD Foundation." +msgstr "NetBSD is a registered trademark of the NetBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:24 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:32 article.translate.xml:34 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/rc-scripting/article.xml 44709 " +"2014-04-29 21:39:27Z wblock $" +msgstr "$FreeBSD$" + +#. (itstool) path: abstract/para +#: article.translate.xml:37 +msgid "" +"Beginners may find it difficult to relate the facts from the formal " +"documentation on the BSD rc.d framework with the " +"practical tasks of rc.d scripting. In this article, we " +"consider a few typical cases of increasing complexity, show rc.d features suited for each case, and discuss how they work. Such an " +"examination should provide reference points for further study of the design " +"and efficient application of rc.d." +msgstr "" +"Os iniciantes podem achar difícil relacionar os fatos da documentação formal " +"do framework rc.d do BSD com as tarefas práticas do " +"script rc.d. Neste artigo, consideramos alguns casos " +"típicos de complexidade crescente, vamos mostrar os recursos do rc." +"d adequados para cada caso e vamos discutir como eles funcionam. " +"Esse exame deve fornecer pontos de referência para um estudo mais " +"aprofundado do design e da aplicação eficiente do rc.d." + +#. (itstool) path: sect1/title +#: article.translate.xml:50 +msgid "Introduction" +msgstr "Introdução" + +#. (itstool) path: sect1/para +#: article.translate.xml:52 +msgid "" +"The historical BSD had a monolithic startup script, /etc/rc. It was invoked by init8 at system boot time " +"and performed all userland tasks required for multi-user operation: checking " +"and mounting file systems, setting up the network, starting daemons, and so " +"on. The precise list of tasks was not the same in every system; admins " +"needed to customize it. With few exceptions, /etc/rc " +"had to be modified, and true hackers liked it." +msgstr "" +"Historicamente o BSD tinha um script de inicialização monolítico, o " +"/etc/rc. Ele era chamado pelo " +"init 8 no momento da inicialização do sistema e executava todas as " +"tarefas necessárias para a operação multi-usuário: verificação e montagem do " +"sistemas de arquivos, configuração de rede, iniciava daemons e assim por " +"diante. A lista precisa de tarefas não era a mesma em todos os sistemas; os " +"administradores precisavam personalizá-lo. Com poucas exceções, o /" +"etc/rc teve que ser modificado, e os verdadeiros hackers gostaram " +"disso." + +#. (itstool) path: sect1/para +#: article.translate.xml:62 +msgid "" +"The real problem with the monolithic approach was that it provided no " +"control over the individual components started from /etc/rc. For instance, /etc/rc could not restart a " +"single daemon. The system admin had to find the daemon process by hand, kill " +"it, wait until it actually exited, then browse through /etc/rc for the flags, and finally type the full command line to start the " +"daemon again. The task would become even more difficult and prone to errors " +"if the service to restart consisted of more than one daemon or demanded " +"additional actions. In a few words, the single script failed to fulfil what " +"scripts are for: to make the system admin's life easier." +msgstr "" +"O problema real com a abordagem monolítica era que ela não fornecia nenhum " +"controle sobre os componentes individuais iniciados a partir do /" +"etc/rc. Por exemplo, o /etc/rc não podia " +"reiniciar um único daemon. O administrador do sistema tinha que encontrar o " +"processo daemon manualmente, matá-lo, esperar até que ele realmente " +"finalizasse, então procurar pelas flags no /etc/rc, e " +"finalmente digitar a linha de comando completa para iniciar o daemon " +"novamente. A tarefa se tornaria ainda mais difícil e propensa a erros se o " +"serviço de reinicialização consistisse em mais de um daemon ou exigisse " +"ações adicionais. Em poucas palavras, o único script não cumpriu o objetivo " +"dos scripts: tornar a vida do administrador do sistema mais fácil." + +#. (itstool) path: sect1/para +#: article.translate.xml:76 +msgid "" +"Later there was an attempt to split out some parts of /etc/rc for the sake of starting the most important subsystems separately. " +"The notorious example was /etc/netstart to bring up " +"networking. It did allow for accessing the network from single-user mode, " +"but it did not integrate well into the automatic startup process because " +"parts of its code needed to interleave with actions essentially unrelated to " +"networking. That was why /etc/netstart mutated into " +"/etc/rc.network. The latter was no longer an ordinary " +"script; it comprised of large, tangled sh1 functions called from " +"/etc/rc at different stages of system startup. However, " +"as the startup tasks grew diverse and sophisticated, the quasi-" +"modular approach became even more of a drag than the monolithic " +"/etc/rc had been." +msgstr "" +"Mais tarde, houve uma tentativa de dividir algumas partes do /etc/" +"rc para iniciar os subsistemas mais importantes separadamente. O " +"exemplo notório foi o /etc/netstart para configurar a " +"rede. Ele permitia acessar a rede a partir do modo single-user, mas não se " +"integrou bem ao processo de inicialização automática porque partes de seu " +"código precisavam intercalar com ações essencialmente não relacionadas à " +"rede. Foi por isso que o /etc/netstart mudou para " +"/etc/rc.network. Este último não era mais um script " +"comum; ele era composto por um emaranhado de funções " +"sh1 chamadas pelo /etc/rc em diferentes " +"estágios da inicialização do sistema. No entanto, a medida que as tarefas de " +"inicialização cresciam variadas e sofisticadas, a abordagem quase " +"modular tornou-se ainda mais engessada do que o monolítico " +"/etc/rc." + +#. (itstool) path: sect1/para +#: article.translate.xml:94 +msgid "" +"Without a clean and well-designed framework, the startup scripts had to bend " +"over backwards to satisfy the needs of rapidly developing BSD-based " +"operating systems. It became obvious at last that more steps are necessary " +"on the way to a fine-grained and extensible rc system. " +"Thus BSD rc.d was born. Its acknowledged fathers were " +"Luke Mewburn and the NetBSD community. Later it was imported into FreeBSD. " +"Its name refers to the location of system scripts for individual services, " +"which is in /etc/rc.d. Soon we will learn about more " +"components of the rc.d system and see how the " +"individual scripts are invoked." +msgstr "" +"Sem um framework limpo e bem projetado, os scripts de inicialização tiveram " +"que se curvar para satisfazer as necessidades de desenvolvimento rápido dos " +"sistemas operacionais baseados no BSD. Tornou-se óbvio, finalmente, que mais " +"passos eram necessários no caminho para construção de um sistema " +"rc extensível e customizável. Assim nasceu o BSD " +"rc.d. Seus pais reconhecidos foram o Luke Mewburn e a " +"comunidade do NetBSD. Mais tarde ele foi importado para o FreeBSD. Seu nome " +"se refere à localização dos scripts do sistema para serviços individuais, " +"que é o /etc/rc.d. Em breve, vamos aprender sobre mais " +"componentes do sistema rc.d e vamos ver como os scripts " +"individuais são invocados." + +#. (itstool) path: sect1/para +#: article.translate.xml:107 +msgid "" +"The basic ideas behind BSD rc.d are fine " +"modularity and code reuse. Fine " +"modularity means that each basic service such as a " +"system daemon or primitive startup task gets its own " +"sh1 script able to start the service, stop it, reload it, check " +"its status. A particular action is chosen by the command-line argument to " +"the script. The /etc/rc script still drives system " +"startup, but now it merely invokes the smaller scripts one by one with the " +" argument. It is easy to perform shutdown tasks as " +"well by running the same set of scripts with the " +"argument, which is done by /etc/rc.shutdown. Note how " +"closely this follows the Unix way of having a set of small specialized " +"tools, each fulfilling its task as well as possible. Code reuse means that common operations are implemented as " +"sh1 functions and collected in /etc/rc.subr. " +"Now a typical script can be just a few lines' worth of " +"sh1 code. Finally, an important part of the rc.d framework is rcorder8, which helps " +"/etc/rc to run the small scripts orderly with respect " +"to dependencies between them. It can help /etc/rc.shutdown, too, because the proper order for the shutdown sequence is " +"opposite to that of startup." +msgstr "" +"As idéias básicas por trás do BSD rc.d são " +"modularidade fina e reutilização de código. Modularidade fina significa que cada " +"serviço básico, como um daemon do sistema ou uma tarefa de " +"inicialização primitiva, obtém seu próprio script " +"sh capaz de iniciar o serviço, pará-lo, recarregá-lo e verificar " +"seu status. Uma ação específica é escolhida pelo argumento da linha de " +"comando para o script. O script /etc/rc ainda comanda a " +"inicialização do sistema, mas agora ele simplesmente invoca os scripts " +"menores um por um com o argumento . É fácil executar " +"tarefas de desligamento executando o mesmo conjunto de scripts com o " +"argumento , o que é feito pelo /etc/rc." +"shutdown. Observe como isso segue de perto o modo Unix de ter um " +"conjunto de pequenas ferramentas especializadas, cada uma cumprindo sua " +"tarefa da melhor forma possível. Reutilização de código " +"significa que operações comuns são implementadas como funções " +"sh1 e coletadas em /etc/rc.subr . Agora, um " +"script típico pode conter apenas algumas linhas de código " +"sh1 . Finalmente, uma parte importante do framework do rc." +"d é rcorder " +"8 , o qual ajuda o /etc/rc a executar os pequenos scripts ordenadamente em relação às " +"dependências entre eles. Ele também pode ajudar o /etc/rc." +"shutdown, porque a ordem apropriada para a sequência de " +"encerramento é oposta à da inicialização." + +#. (itstool) path: sect1/para +#: article.translate.xml:133 *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Wed Sep 12 02:10:26 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE08110A619E; Wed, 12 Sep 2018 02:10:25 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83D63948F6; Wed, 12 Sep 2018 02:10:25 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 7E65F2027D; Wed, 12 Sep 2018 02:10:25 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8C2APlr027997; Wed, 12 Sep 2018 02:10:25 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8C2APgO027996; Wed, 12 Sep 2018 02:10:25 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809120210.w8C2APgO027996@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Wed, 12 Sep 2018 02:10:25 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52248 - head/pt_BR.ISO8859-1/articles/problem-reports X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: head/pt_BR.ISO8859-1/articles/problem-reports X-SVN-Commit-Revision: 52248 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 02:10:26 -0000 Author: ebrandi Date: Wed Sep 12 02:10:25 2018 New Revision: 52248 URL: https://svnweb.freebsd.org/changeset/doc/52248 Log: pt_BR.ISO8859-1/articles/problem-reports: converted to .po * content synchronized with en_US document (rev 51348) * article.xml converted to .po * .po file was translated to pt_BR * pt_BR.po and article.xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file. Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/problem-reports/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/problem-reports/article.xml (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/problem-reports/article.xml ============================================================================== --- head/pt_BR.ISO8859-1/articles/problem-reports/article.xml Wed Sep 12 00:52:17 2018 (r52247) +++ head/pt_BR.ISO8859-1/articles/problem-reports/article.xml Wed Sep 12 02:10:25 2018 (r52248) @@ -1,1063 +1,342 @@ - - - -
    - Escrevendo Relatórios de Problema no &os; - + + Escrevendo Relatórios de Problemas para o FreeBSD - &tm-attrib.freebsd; - &tm-attrib.cvsup; - &tm-attrib.ibm; - &tm-attrib.intel; - &tm-attrib.sparc; - &tm-attrib.sun; - &tm-attrib.general; + FreeBSD is a registered trademark of the FreeBSD Foundation. + IBM, AIX, OS/2, PowerPC, PS/2, S/390, and ThinkPad are trademarks of International Business Machines Corporation in the United States, other countries, or both. + Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. + SPARC, SPARC64, and UltraSPARC are trademarks of SPARC International, Inc in the United States and other countries. SPARC International, Inc owns all of the SPARC trademarks and under licensing agreements allows the proper use of these trademarks by its members. + Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the â„¢ or the ® symbol. - $FreeBSD$ + $FreeBSD$ - $FreeBSD$ + $FreeBSD$ - Este artigo descreve qual a melhor forma de formular e - de submeter um relatório de problema para Projeto - &os;. + Este artigo descreve como redigir e submeter um bom relatório de problemas ao Projeto FreeBSD. - Dag-ErlingSmørgravContribuido por + Dag-Erling Smørgrav Contribuído por - MarkLinimon + Mark Linimon - relatório de problema - + relatórios de problemas
    - Introdução + Introdução - Uma das experiências mais frustrantes que - alguém pode ter como um usuário de um software - é submeter um relatório sobre um problema - que está enfrentando apenas para vê-lo ser - sumariamente fechado com uma informação curta - e pouco útil do tipo isto não é - um bug ou ainda este relatório de - problema não procede. Da mesma forma, uma das - experiências mais frustrantes para um desenvolvedor de - software é ser inundado com relatórios de - problemas que na verdade não são realmente - relatórios de problemas, mas sim - solicitações de suporte, ou então que - contenham pouca ou nenhuma informação sobre como - o problema ocorre e sobre como proceder para - reproduzi-lo. - - Este documento tem por objetivo descrever como escrever - bons relatórios de problema. Mas o que vem a ser um - bom relatório de problema? Bem, indo direto ao ponto, - um bom relatório de problema é aquele que se - pode analisar e tratar rapidamente, para a - satisfação mútua do usuário e do - desenvolvedor. - - Embora o foco primário deste artigo seja a - elaboração de relatórios de problemas no - &os;, a maior parte das recomendações deve - aplicar-se muito bem a outros projetos de software. - - Observe que este artigo esta organizado de forma - temática, e não de forma cronológica, - desta forma você deve ler o documento inteiro antes - de enviar um relatório de problema, ao invés - de tratá-lo como um tutorial passo-a-passo. + Uma das experiências mais frustrantes que alguém pode ter como usuário de um software é submeter um relatório de problema apenas para vê-lo ser encerrado sumariamente com uma explicação curta e inútil tal como não é um bug ou PR Falso. Da mesma forma, uma das experiências mais frustrantes como desenvolvedor de software é ser inundado com relatórios de problemas que não são realmente relatórios de problemas mas sim pedidos de suporte, ou então por relatórios que contêm pouca ou nenhuma informação sobre o que é o problema e sobre como reproduzi-lo. + + Este documento tenta descrever como escrever bons relatórios de problemas. O que, alguém pergunta, é um bom relatório de problemas? Bem, para ir diretamente para ao ponto, um bom relatório de problema é aquele que pode ser analisado e tratado rapidamente, para a satisfação mútua do usuário e do desenvolvedor. + + Embora o foco principal deste artigo esteja nos relatórios de problemas do FreeBSD, a maioria das recomendações deve se aplicar muito bem a outros projetos de software. + + Observe que este artigo é organizado por temas, não de uma forma cronológica. Leia todo o documento antes de enviar um relatório de problemas, em vez de tratá-lo como um tutorial passo a passo.
    - Quando enviar um relatório de problema + Quando Enviar um Relatório de Problemas - Existem muitos tipos de problemas, e nem todos eles devem - gerar um relatório de problema. É claro, - ninguém é perfeito e em algumas ocasiões - você terá certeza de que encontrou um bug em um - determinado software quando na verdade você compreendeu - errado a sintaxe de um comando ou mesmo cometeu um erro de - digitação em um arquivo de - configuração (o que por sua vez pode indicar - uma documentação pouco detalhada ou - então um tratamento inadequado do erro por parte - da aplicação). Existem ainda muitas outras - situações nas quais enviar um relatório de - problema claramente não é - a melhor ação a ser tomada, e só vai - servir para frustrar a você e aos desenvolvedores. Em - contrapartida, existem situações nas quais - é recomendado que você nos envie um - relatório de problema sobre outras coisas que - não um bug, como por exemplo para nos enviar uma - sugestão de melhoria ou um pedido de uma nova - funcionalidade. - - Então como você irá diferenciar o que - é e o que não é um bug? Existe uma regra - de ouro que diz que o seu problema não - é um bug se ele pode ser expresso como uma - pergunta (normalmente na forma Como eu faço - X ou Onde eu posso encontrar Y). Na - maior parte das vezes não será sempre - tão claro desta forma, mas a regra acima cobre a grande - maioria dos casos. Se você estiver procurando por uma - resposta, considere enviar a sua pergunta para - &a.questions;. - - Veja alguns casos nos quais pode ser apropriado enviar um - relatório de problema sobre algo que não é - um bug: + Existem muitos tipos de problemas, e nem todos devem gerar um relatório de problemas. Naturalmente, ninguém é perfeito, e haverá momentos em que o que parece ser um bug em um programa é, na verdade, um equívoco na sintaxe de um comando ou um erro tipográfico em um arquivo de configuração (embora isto por si só possa ser um indicativo de uma documentação deficiente ou de deficiências no manuseio de erros pelo aplicativo). Existem ainda muitos casos em que submeter um relatório de problema claramente não é o curso de ação correto, e só servirá para frustrar tanto o usuário e quanto o desenvolvedor. Por outro lado, existem casos em que pode ser apropriado enviar um relatório de problema sobre algo diferente de um bug - tal como um aprimoramento ou um novo recurso, por exemplo. + Então, como se determina o que é um bug e o que não é? Como uma regra simples, o problema não é um bug se ele puder ser expresso como uma pergunta (geralmente na forma Como faço X? ou Onde posso encontrar Y?). Nem sempre é tão preto e branco, mas a regra da pergunta cobre a grande maioria dos casos. Ao procurar por uma resposta, considere colocar a questão na lista de discussão de perguntas gerais sobre o FreeBSD. + + Considere estes fatores ao enviar PRs sobre ports ou outros softwares que não fazem parte do próprio FreeBSD: + - Pedidos de melhorias nas funcionalidades. Geralmente - é uma boa idéia debater estas propostas nas - listas de discussão antes de enviá-las em um - relatório de problemas. + Por favor, não envie relatórios de problemas que simplesmente afirmam que uma versão mais nova de um aplicativo está disponível. Os mantenedores de ports são notificados automaticamente pelo portscout quando uma nova versão de um aplicativo fica disponível. Patches para atualizar um port para uma versão mais recente do software são sempre bem-vindos. - Notificações sobre - atualizações de softwares mantidos - externamente (principalmente do ports, mas também - de componentes do sistema base como, por exemplo, o BIND e - vários outros utilitários GNU). + Para ports não mantidos (O seu MAINTAINER é ports@FreeBSD.org), é improvável que um PR que não tenha um patch incluído seja escolhido para ser trabalhado por um committer. Para se tornar o mantenedor de um port não mantido, envie um PR com o pedido (será ótimo se o pedido vier com um patch, mas isso não é obrigatório). + - Para os ports sem manutenção - (aqueles nos quais a variável - MAINTAINER contém - ports@FreeBSD.org), essas - notificações de atualização - podem ser capturadas por um committer - interessado, ou você pode ser solicitado a fornecer - um patch para atualizar o port; - disponibilizar este patch antecipadamente - irá melhorar de forma significativa as suas chances - de ter o port atualizado rapidamente. - - Se o port possui um mantenedor, o envio de um - relatório de problema comunicando sobre o - lançamento de uma nova versão geralmente - não é muito útil uma vez que eles geram - trabalho adicional para os committers, - e o mantenedor provavelmente já tem conhecimento de - que existe uma nova versão, ele provavelmente - já trabalhou com os desenvolvedores para - atualizá-lo e está provavelmente executando - testes para verificar se não existem problemas, - etc. - - Em ambos os casos, você irá obter melhores - resultados se seguir o processo descrito no Porter's Handbook. - (Talvez você também queira ler o artigo - Contribuindo para a Coleção de Ports - do &os;.) + + Em ambos os casos, seguir o processo descrito no Porter's Handbook produzirá os melhores resultados. (Você também pode desejar ler a seção Contribuindo para a Coleção de Ports do FreeBSD.) - Um bug que não pode ser reproduzido, raramente - será corrigido. Se o bug ocorreu uma única - vez e você não consegue reproduzi-lo, e - se aparentemente ele não ocorre com mais ninguém, - as chances são de que nenhum dos desenvolvedores - será capaz de reproduzir ou de saber o que está - errado. Isso não significa que não seja - possível, mas significa que a probabilidade do seu - relatório de problema resultar na correção - do bug é muito pequena. Para piorar a - situação, muitas vezes este tipo de erro - é, na realidade, causado por falhas nos discos - rígidos ou por superaquecimento do processador — - sempre que possível você deve tentar excluir estas - causas antes de enviar um relatório de problema. + Um bug que não pode ser reproduzido raramente pode ser corrigido. Se o bug ocorreu apenas uma vez e você não pode reproduzi-lo, e não parece acontecer com mais ninguém, é muito provável que nenhum dos desenvolvedores consiga reproduzi-lo ou descobrir o que está errado. Isso não significa que isso não tenha acontecido, mas significa que as chances do seu relatório de problema levar à correção do bug são muito pequenas. Para piorar, muitas vezes esses tipos de bugs são causados por discos rígidos com defeito ou por processadores superaquecidos - sempre que possível você deve tentar descartar essas causas antes de enviar um PR. - Em seguida, para decidir a quem você deve apresentar - o seu relatório de problema, você precisa - entender que o &os; é composto de vários - elementos de software diferentes: - + Em seguida, para decidir para quem você deve enviar seu relatório de problema, você precisa entender que o software que compõe o FreeBSD é composto por vários elementos diferentes: + - Código na base do sistema que é escrito - e mantido por colaboradores do &os;, tais como o Kernel, a - biblioteca C, os drivers de dispositivos (categorizados - como kern); os utilitários - binários (bin); as páginas - de manual e a documentação - (docs); e as páginas web - (www). Todos os bugs nestas - áreas devem ser reportados para os desenvolvedores - do &os; + Código no sistema base que é escrito e mantido por contribuidores do FreeBSD, como o kernel, a biblioteca C e os drivers de dispositivo (categorizados como kern); os utilitários binários (bin); as páginas de manual e documentação (docs); e as páginas web (www). Todos os erros nestas áreas devem ser reportados aos desenvolvedores do FreeBSD. - Código na base do sistema que é escrito - e mantido por outros, e que foram adaptados e importados - no &os;. Exemplos incluen bind, - &man.gcc.1;, e &man.sendmail.8;. A maioria dos bugs nestas - áreas devem ser reportados para os desenvolvedores do - &os;; mas em alguns casos pode ser necessário - reportá-los aos autores originais, caso o problema - não seja especifico do &os;. Normalmente estes bugs - irão ficar sob as categorias bin - ou gnu. + Código no sistema base que é escrito e mantido por outras pessoas, o qual é importado e adaptado para o FreeBSD. Exemplos incluem o clang1 e o sendmail8. A maioria dos bugs nessas áreas deve ser reportada aos desenvolvedores do FreeBSD; mas em alguns casos eles podem precisar ser relatados aos autores originais se os problemas não forem específicos do FreeBSD. - Os aplicativos individuais que não estão - na base do sistema, mas que fazem parte da - coleção de Ports do &os; (Categoria - ports). A maioria destes aplicativos - não são escritos por desenvolvedores do - &os;; o que o &os; oferece é apenas um sistema para - facilitar a instalação do aplicativo. - Portanto, você deve relatar um problema para os - desenvolvedores do &os; apenas quando você acreditar - que o problema é específico do &os;, caso - contrário, você deve reportá-lo aos - autores do software. + Aplicativos individuais que não estão no sistema base, mas que são parte da coleção de ports do FreeBSD (categoria ports). A maioria desses aplicativos não são escritos por desenvolvedores do FreeBSD; o que o FreeBSD fornece é meramente um framework para instalar o aplicativo. Portanto, apenas relate um problema para os desenvolvedores do FreeBSD quando o problema for considerado específico do FreeBSD; caso contrário, informe aos autores do software. - - A seguir você deve verificar se o problema é - ou não atual. Existem poucas coisas que aborrecem um - desenvolvedor mais do que receber um relatório de - problema a respeito de um bug que ele já corrigiu. - - Se o problema está na base do sistema, você - deverá primeiro ler a seção do FAQ sobre - - Versões do &os;, se você não estiver - familiarizado com o tema. Não é possível - para o &os; corrigir problemas em versões muito antigas - do sistema base, desta forma enviar um relatório de - problema sobre um bug em uma versão muito antiga vai - provavelmente resultar apenas em um desenvolvedor aconselhando - que você atualize o seu sistema para uma versão - suportada para ver se o problema ainda ocorre. A equipe - de Security Officer mantém a - lista de versões - suportadas. + Em seguida, verifique se o problema é oportuno. Há poucas coisas que incomodarão mais um desenvolvedor do que receber um relatório de problemas sobre um bug que ele já corrigiu. - Se o problema está em um port, observe que - você deverá primeiro atualizar seu sistema para a - versão mais atual da coleção de ports e ver - se o problema ainda se aplica. Devido ao ritmo acelerado de - mudanças nestas aplicações, é - inviável para o &os; suportar qualquer coisa que - não seja obrigatoriamente a versão mais - recente, e problemas com uma versão antiga do - aplicativo simplesmente não podem ser corrigidos. + Se o problema estiver no sistema base, primeiro leia a seção Versões do FreeBSD do FAQ, se você ainda não estiver familiarizado com o tópico. Não é possível para o FreeBSD consertar problemas em nada além de certas branchs recentes do sistema base, de forma que enviar um relatório de bug sobre uma versão mais antiga provavelmente resultará em um desenvolvedor aconselhando você a atualizar para uma versão suportada para ver se o problema ainda continua ocorrendo. A equipe do Security Officer mantém a lista das versões suportadas . + + Se o problema estiver em um port, observe que você deverá primeiro atualizar para a versão mais recente da Coleção de Ports e verificar se o problema ainda se aplica. Devido ao ritmo acelerado de mudanças nesses aplicativos, é inviável que o FreeBSD ofereça suporte para qualquer coisa que não seja absolutamente a versão mais recente e os problemas com versões mais antigas de aplicativos simplesmente não podem ser corrigidos.
    - Preparação + Preparativos - Uma boa regra a ser seguida sempre é realizar uma - busca a respeito do assunto antes de enviar um relatório - de problema. Pode ser que o seu problema já tenha sido - reportado anteriormente; pode ser que esteja sendo debatido nas - listas de discussão ou que tenha sido recentemente; pode - até ser que o problema já tenha sido corrigido em - uma versão mais recente do que a que você - está utilizando. Você deve portanto verificar - em todos os lugares óbvios antes de enviar o - relatório de problema. Para o &os;, isto - significa: - + Uma boa regra a seguir é sempre fazer uma pesquisa sobre o tema antes de enviar um relatório de problemas. Talvez o problema já tenha sido relatado anteriormente; talvez esteja sendo discutido nas listas de discussão, ou foi discutido recentemente; pode até mesmo já estar corrigido em uma versão mais recente da que você está executando. Portanto, você deve verificar todos os lugares óbvios antes de enviar seu relatório de problemas. Para o FreeBSD, isso significa: + - A lista de Perguntas e Respostas mais - Frequentes sobre o &os; (FAQ). A FAQ tem por - objetivo fornecer respostas para uma grande variedade de - perguntas, tais como as que dizem respeito a compatibilidade de - hardware, aplicações - do usuário, Configuração - do kernel, etc. + A lista das Perguntas Mais Freqüentes (FAQ) sobre o FreeBSD. A FAQ tenta fornecer respostas para uma ampla variedade de perguntas, como aquelas relacionadas à compatibilidade de hardware , aplicativos de usuário e configuração do kernel. - As - listas de discussão — se você - não está inscrito, utilize a - busca do histórico no web site do - &os;. Se o seu problema não tiver sido discutido nas - listas, você pode tentar enviar uma mensagem sobre ele - e aguardar alguns dias para ver se alguém consegue - perceber algo que você tenha deixado passar - desapercebido. + As listas de discussão - se você não está inscrito, faça uma pesquisa nos arquivos históricos das listas no site do FreeBSD. Se o problema não tiver sido discutido nas listas, você pode tentar postar uma mensagem sobre ele e aguardar alguns dias para ver se alguém consegue detectar algo que foi esquecido. - Opcionalmente, na internet inteira — utilize seu - mecanismo de busca preferido para localizar - referências sobre o seu problema. Você pode - encontrar referências a ele em mensagens de listas de - discussão ou de grupos de noticias dos quais - você nunca ouviu falar ou nos quais sequer pensou - em procurar. + Opcionalmente, na web toda - use seu mecanismo de pesquisa favorito para localizar qualquer referência ao problema. Você pode até receber hits de listas de discussão arquivadas ou grupos de notícias que você não conhecia ou que não pensou em pesquisar. - Na sequência, verifique o - banco de dados com os relatórios de problema do - &os; (GNATS). A menos que o seu problema seja - recente ou muito obscuro, existe uma boa chance dele - já ter sido reportado. + Em seguida, faça uma pesquisa no banco de dados de Relatórios de Problemas do FreeBSD (Bugzilla). A menos que o problema seja recente ou obscuro, há uma boa chance de que ele já tenha sido relatado. - E o mais importante, você deve verificar se a - documentação existente no código base - não endereça o seu problema. - - Para o código base do &os; você deve - estudar cuidadosamente o conteúdo do arquivo - /usr/src/UPDATING disponível no - seu sistema de arquivos ou a sua versão mais - recente no - Repositório Subversion. (Esta - informação é vital se você - estiver atualizando de uma versão para outra - — especialmente se estiver atualizando para o - &os.current;). - - No entanto, se o problema é com algo que foi - instalado como uma parte da coleção de ports - do &os; você deve consultar o - /usr/ports/UPDATING (para os ports - individuais) ou o /usr/ports/CHANGES - (para mudanças que afetam a Coleção de - Ports inteira). Estes arquivos também estão - disponíveis no SVNWeb, nos urls http://svnweb.freebsd.org/ports/head/UPDATING - e http://svnweb.freebsd.org/ports/head/CHANGES - respectivamente. + Mais importante ainda, tente verificar se a documentação existente não endereça o seu problema. + + Para o código fonte do FreeBSD, você deve estudar cuidadosamente o conteúdo do /usr/src/UPDATING em seu sistema ou a última versão disponível em https://svnweb.freebsd.org/base/head/UPDATING?view=log. (Esta é uma informação vital se você estiver atualizando de uma versão para outra - especialmente se você estiver atualizando para a Branch FreeBSD-CURRENT). + + No entanto, se o problema estiver em algo que foi instalado como parte da coleção de ports do FreeBSD, você deve consultar /usr/ports/UPDATING (para ports individuais) ou /usr/ports/CHANGES (para alterações que afetam toda a coleção de ports). O https://svnweb.freebsd.org/ports/head/UPDATING?view=log e o https://svnweb.freebsd.org/ports/head/CHANGES?view=log também estão disponíveis via svnweb.
    - Escrevendo o Relatório de Problema + Escrevendo o Relatório do Problema - Agora que você decidiu que o seu assunto merece um - relatório de problema (PR), e que ele é um - problema do &os;, é hora de escrever o relatório - em si. Mas antes de entrarmos na mecânica do programa - utilizado para gerar e enviar os PRs, aqui estão - algumas dicas e truques para ajudá-lo a garantir que o - seu PR será o mais efetivo possível. - -
    - Dicas e truques para escrever um bom relatório de - problema. + Agora que você decidiu que seu problema merece um relatório de problema e que ele é um problema especifico do FreeBSD, é hora de escrever o relatório de problema. Antes de entrarmos na mecânica do sistema utilizado para gerar e enviar os PRs, aqui estão algumas dicas e truques para ajudar a garantir que seu o PR seja mais eficaz. +
    + Dicas e Truques para Escrever um Bom Relatório de Problemas + - Não deixe a linha de - Synopsis (sinopse) em branco. - Os PRs são enviados para listas de discussão - no mundo todo (nas quais a Synopsis - é utilizada como linha de - Subject:), além de serem - armazenados em um banco de dados. Qualquer pessoa - que vier a navegar no banco de dados pelas - sinopses, e encontrar um PR com a linha de assunto - em branco, tende a pulá-lo. Lembre-se que os PRs - permanecem na base de dados até que sejam fechados - por alguém; os anônimos normalmente - irão desaparecer em meio ao ruído. + Não deixe a linha Synopsis (Sinopse) vazia. Os PRs são enviados para listas de discussão no mundo todo (nas quais Synopsis é usado para na linha de Subject:), além de serem armazenadas em um banco de dados. Qualquer pessoa que vier a navegar no banco de dados pelas sinopses, e encontrar um PR com a linha de assunto em branco, tende a pulá-lo. Lembre-se que os PRs permanecem na base de dados até que sejam fechados por alguém; os anônimos normalmente irão desaparecer em meio ao ruído. - Evite utilizar uma Synopsis - (sinopse) fraca. Você não - pode assumir que alguém que esteja lendo o seu PR - conheça todo o contexto que motivou o seu envio, - desta forma quanto mais informação - você fornecer, melhor. Por exemplo, a que - parte do sistema o problema se aplica? O problema - ocorre durante a instalação ou durante a - execução do sistema? Para ilustrar, ao - invés de utilizar Synopsis: o - portupgrade está quebrado, veja o - quão mais claro e mais eficiente seria - utilizar Synopsis: port sysutils/portupgrade - gerando coredumps no -current. (No caso de um - port, é especialmente útil ter a categoria - e o nome do port na linha de sinopse.) + Evite usar uma Sinopse (Sinopse) fraca. Você não deve presumir que alguém que esteja lendo seu PR conheça o contexto que motivou o seu envio, desta forma, quanto mais informação você fornecer, melhor. Por exemplo, a parte do sistema o problema se aplica? O problema ocorre durante a instalação ou durante a execução do sistema? Para ilustrar, em vez de usa Sinopse: o portupgrade está quebrado, veja o quanto mais informativo isso parece: Sinopse: port ports-mgmt/portupgrade gerando coredumps on -current. (No caso de um port, é especialmente útil ter tanto o nome da categoria quanto o nome do port na linha Sinopse.) - Se você possui um patch, - mencione-o. Um PR que inclui um - patch é muito mais - provável de ser analisado do que um sem. Se - você estiver incluindo um, coloque a palavra - [patch] no inicio da linha - de sinopse. (Embora não seja obrigatório - utilizar exatamente esta palavra, por - convenção, é ela que é - utilizada.) + Se você tem um patch, mencione-o. Um PR com um patch incluído é muito mais provável de ser analisado do que um sem. Se você está incluindo um, coloque a palavra [patch] (incluindo os colchetes) no início da linha de Sinopse. (Embora não seja obrigatório usar exatamente essa palavra, por convenção, essa é a que é usada.) - Se você é um - maintainer (mantenedor), - diga-o. Se você está mantendo uma - parte do código fonte (por exemplo, um port), - você deve considerar a possibilidade de incluir as - palavras [maintainer update] (incluindo - os colchetes) no inicio da linha de sinópse e - deve definir a class - (classe) do seu PR para maintainer-update. Desta forma - qualquer committer que manusear o seu - PR não terá de verificar o - Makefile do port, para certificar-se - de que a atualização foi enviada pelo - maintainer. + Se você é um mantenedor, diga. Se você está mantendo uma parte do código fonte (por exemplo, um port), você pode considerar adicionar as palavras [atualização do mantenedor] (incluindo os colchetes) no início da sua linha de sinopse, e você definitivamente deve definir a Class (Classe) do seu PR para maintainer-update. Desta forma, qualquer committer que lide com seu PR não terá que verificar o Makefile do port, para certificar-se de que a atualização foi enviada pelo maintainer. - Seja específico. Quanto - mais informações você fornecer sobre o - problema que você está tendo, melhores - serão as suas chances de obter uma resposta. + Seja específico. Quanto mais informações você fornecer sobre o problema que está tendo, maiores serão suas chances de obter uma resposta. - Inclua a versão do &os; que você - está utilizando (existe um lugar para colocar - esta informação, veja abaixo) e em qual - arquitetura. Você incluir a - informação se está executando a - partir de um Release (e.g. de um CDROM ou Download), - ou a partir de um sistema mantido com o &man.cvsup.1; - (e neste caso, quando foi atualizado pela ultima - vez). Se você estiver utilizando o - &os.current;, esta vai ser a primeira coisa que - alguém irá lhe perguntar, porque as - correções (especialmente para os - problemas de alto nível) tendem a serem - realizadas muito rapidamente, e espera-se que os - usuários do &os.current; mantenham-se - atualizados. + Inclua a versão do FreeBSD que você está utilizando (há um lugar para colocar essa informação, veja abaixo) e em qual arquitetura. Você deve incluir se você está executando a partir de uma release (por exemplo, de um CD-ROM ou feito um download), ou de um sistema mantido pelo Subversion (e, caso seja afirmativo, em qual número de revisão você está). Se você estiver utilizando a branch FreeBSD-CURRENT, essa é a primeira coisa que alguém vai perguntar, porque as correções (especialmente para problemas de alto nível) tendem a ser realizadas muito rapidamente, e é esperado que usuários do FreeBSD-CURRENT se mantenham atualizados. - Inclua quais opções globais - você especificou no seu - make.conf. - Observação: É conhecido que - utilizar -O2 (e acima disso) com o - &man.gcc.1; gera problemas em muitas - situações. Apesar dos desenvolvedores - do &os; aceitarem patches, eles normalmente não - estão dispostos a investigar este tipo de - problema por uma simples falta de tempo e de - voluntários, e ao invés disso podem - responder apenas que isto não é - suportado. + Inclua quais opções globais você especificou em seu make.conf. Nota: sabemos que especificar -O2 e acima com o gcc1 gera bugs em muitas situações. Embora os desenvolvedores do FreeBSD aceitem patches, eles geralmente não estarão dispostos a investigar tais problemas devido a simples falta de tempo e de voluntários, ao invés disso podem apenas responder que isso simplesmente não é suportado. - Se o problema pode ser reproduzido facilmente, - inclua informações para possibilitar - que ele seja reproduzido pelos desenvolvedores. Se - o problema só pode ser - demonstrado com a entrada de um conjunto de dados - específico, você deverá incluir um - exemplo destas informações, além - de informar qual é resultado - atual (errado) e qual era o resultado esperado - (correto). Se o conjunto de dados for muito grande ou - se o mesmo não puder ser tornado - público, tente criar um arquivo com o - mínimo - de informações necessárias para - replicar o problema, e que possa ser incluído - no seu PR. + Se o problema puder ser reproduzido facilmente, inclua informações que irão ajudar um desenvolvedor a reproduzi-lo. Se um problema puder ser demonstrado com uma entrada específica, então inclua um exemplo desta entrada se possível, e inclua tanto a saída real quanto a esperada. Se esses dados forem grandes ou não puderem ser tornados públicos, então tente criar um arquivo pequeno que exiba o mesmo problema e que possa ser incluído no PR. - - Se for um problema com o kernel, esteja preparado para - fornecer as seguintes informações - (Você não precisa fornecer estas - informações por padrão, o que - só tende a encher o banco de dados, mas - você deve incluir os trechos acreditar que - são relevantes): + Se este for um problema do kernel, esteja preparado para fornecer as seguintes informações. (Você não precisa incluí-las por padrão, o que apenas tende a preencher o banco de dados, mas você deve incluir os trechos que considera ser relevantes): + - A configuração do seu kernel - (incluindo quais dispositivos de hardware - você tem instalados) + sua configuração do kernel (incluindo quais dispositivos de hardware você tem instalado) + - Se você tem ou não - opções de depuração - habilitadas (tais como - WITNESS), e em caso afirmativo, - se o problema continua ocorrendo quando - você altera a lógica de - configuração destas - opções + independente de você ter ou não opções de debug habilitadas (como WITNESS), e se tiver, se o problema persiste quando você muda o sentido da opção + - O texto completo de qualquer - backtrace, - panic e outras - mensagens no console, ou os registros do - /var/log/messages, caso tenha - sido gerado algum + o texto completo de qualquer backtrace, panic ou outra mensagens de console, ou registros em /var/log/messages, se houver sido gerado + - A saída do pciconf - -l e as partes relevantes da - saída do dmesg se o - problema estiver relacionado a um componente de - hardware + a saída de pciconf -l e partes relevantes da saída do comando dmesg se o seu problema estiver relacionado a uma peça específica de hardware + - O fato de que você leu o - src/UPDATING e que o seu - problema não está listado ali - (é certeza que alguém vai - perguntar) + o fato de você ter lido src/UPDATING e o seu problema não estar listado lá (alguém pode perguntar) + - Se você consegue ou não executar - outro kernel (Isto é para poder descartar a - possibilidade de ser um problema de hardware tais - como falha nos discos rígidos e - superaquecimento dos processadores, cujos - sintomas podem se confundir com problemas no - kernel) + independente de você poder executar qualquer outro kernel como um fallback (isso é para descartar problemas relacionados a hardware, como discos com falhas e CPUs superaquecidas, que podem se passar por problemas de kernel) - Se for um problema com um port, esteja preparado - para fornecer as seguintes informações - (Você não precisa fornecer estas - informações por padrão, o que - só tende a encher o banco de dados, mas - você deve incluir os trechos acreditar que - são relevantes): + Se este for um problema de algum port, esteja preparado para fornecer as seguintes informações. (Você não precisa incluí-las por padrão, o que apenas tende a preencher o banco de dados, mas você deve incluir trechos que você considera relevantes): - Quais ports você tem instalados + quais ports você instalou + - As variáveis de ambiente que substituem - os padrões do - bsd.port.mk, como por exemplo - PORTSDIR + quaisquer variáveis de ambiente que sobreescrevem as variáveis padrões em bsd.port.mk, assim como PORTSDIR + - O fato de que você leu o - ports/UPDATING e que o seu - problema não está listado ali - (é certeza que alguém vai - perguntar) + o fato de você ter lido ports/UPDATING e o seu problema não estar listado lá (é garantido que alguém irá perguntar) - - - Evite pedidos vagos de novas - funcionalidades. Os PRs no formato - alguém realmente deveria implementar algo - que faz isso e aquilo são menos - prováveis de obterem uma resposta do - que os que são mais específicos. Lembre-se, - o código está disponível para todos, - de forma que se você deseja uma nova funcionalidade, - a melhor maneira de ter certeza de que ela - será incluída é começar a - trabalhar! Também considere o fato de que - muitas destas sugestões fariam mais sentido - como um tópico de discussão na - freebsd-questions do que - como uma entrada no banco de dados de PRs, como - discutido acima. + Evite requisições vagas de novas funcionalidades. Os PRs no formato alguém realmente deve implementar algo que faz isso e aquilo têm menor probabilidade de obter resultados do que requisições muito específicas. Lembre-se, o código fonte está disponível para todos, então se você quiser uma nova funcionalidade, a melhor maneira de garantir que ela seja incluída é começar a trabalhar! Considere também o fato de que muitas coisas como essa seriam um tópico melhor para a discussão sobre freebsd-questions do que uma entrada no banco de dados de PR, como discutido acima. - Certifique-se de que ninguém tenha - submetido um PR semelhante antes. Embora isso - já tenha sido mencionado anteriormente, faz sentido - repetir aqui. Esta verificação irá - lhe tomar apenas 1 ou 2 minutos no uso do - mecanismo de busca do banco de dados de PRs. - (é claro, todos são culpados de já - terem esquecido de fazer isso de uma vez ou outra.) + Certifique-se de que ninguém mais tenha submetido um PR similar. Embora isso já tenha sido mencionado acima, vale a pena repetir aqui. Leva apenas um ou dois minutos para usar o mecanismo de busca baseado na Web em https://bugs.freebsd.org/bugzilla/query.cgi. (Claro, todo mundo é culpado de esquecer de fazer isso de vez em quando.) - - Relate apenas um problema em cada - relatório. Evite incluir dois ou mais - problemas em um mesmo relatório caso eles - não estejam relacionados. Quando - você submeter um patch, evite - adicionar várias funcionalidades ou corrigir - vários bugs em um mesmo PR, a menos que eles - sejam estritamente relacionados — Este tipo de - PR muitas vezes demanda mais tempo para ser - resolvido. + Relate um problema apenas através do Relatório de Problemas. Evite incluir dois ou mais problemas dentro do mesmo relatório, a menos que estejam relacionados. Ao enviar patches, evite adicionar várias funcionalidades ou corrigir multiplos bugs no mesmo PR, a menos que eles estejam intimamente relacionados - esses PRs geralmente levam mais tempo para serem resolvidos. - Evite solicitações - polêmicas. Se o seu PR está - relacionado a um tema que foi polêmico no passado, - você deve estar preparado para não somente - disponibilizar um patch, como - também para defender porque o seu - patch é a coisa certa a - se fazer. Como mencionado acima, realizar uma - busca cuidadosa no histórico das listas - de discussão é sempre uma boa - forma de se preparar. + Evite requisições controversas. Se o seu PR aborda uma área que já foi controversa no passado, você provavelmente deverá estar preparado para não apenas oferecer patches, mas também justificar por que os patches são A Coisa Certa A Se Fazer . Como observado acima, uma busca cuidadosa nas listas de discussão usando os arquivos em https://www.FreeBSD.org /search/search.html#mailinglists é sempre uma boa preparação. - Seja educado. Praticamente - todas as pessoas que potencialmente podem trabalhar no - seu PR são voluntários. Ninguém - gosta de receber ordens para fazer algo que eles já - estão fazendo por alguma outra - motivação a qual não é a de - ganho financeiro. Esta é uma boa coisa para ter - sempre em mente num projeto de código - aberto. + Seja educado. Quase todo mundo que potencialmente irá trabalhar em seu PR é um voluntário. Ninguém gosta que digam o que eles tem que fazer quando já estão fazendo por alguma motivação que não seja o ganho monetário. É sempre bom ter isso em mente em projetos de código aberto.
    -
    - Antes de você iniciar +
    + Antes de Começar - Antes de executar o programa &man.send-pr.1;, - certifique-se que a sua variável de ambiente - VISUAL (ou a EDITOR se a - VISUAL não estiver definida) - está definida com seu editor preferido. - - Você também deve certificar-se de que o seu - sistema de entrega de emails esta funcionando corretamente. O - &man.send-pr.1; utiliza mensagens de email para enviar e - rastrear um relatório de problema. Se você - não pode enviar mensagens de email a partir da - máquina na qual está executando o - &man.send-pr.1;, os seus relatórios de problema - não irão chegar até a base de dados - GNATS. Para maiores detalhes de como configurar o sistema de - email no &os;, consulte o capítulo sobre Correio - Eletrônico no Handbook - do FreeBSD. - - Certifique-se de que o seu sistema de email não - irá alterar a formatação da mensagem ao - encaminhá-la para o GNATS. Qualquer - patch que você enviar será - inutilizado, caso o seu sistema de email quebre - automaticamente as linhas, troque - tabulações por espaços em branco ou - altere os caracteres de mudança para uma nova linha, - etc. Entretanto, para as seções de texto - nós pedimos que você quebre manualmente as linhas - próximo dos 70 caracteres, desta forma a versão - web do PR poderá ser lida melhor. - - Considerações similares se aplicam se - você estiver utilizando o formulário web de - submissão de PR ao invés de utilizar o - &man.send-pr.1;. Observe que operações de - copiar-e-colar possuem seus próprios efeitos colaterais - na formatação do texto. Em certos casos, pode - ser necessário usar o &man.uuencode.1; para garantir - que os patches cheguem sem modificações. + Considerações semelhantes se aplicam ao uso do formulário de envio de PR web-based (com base em web). Cuidado com as operações de recortar e colar que podem alterar o espaços em branco ou outras formatações de texto. - Finalmente, se a sua submissão será longa, - você deve preparar o texto do seu - relatório offline, desta forma nada será - perdido no caso de você ter problemas quando for - submetê-lo. Isto pode ser um problema, em especial, - se você estiver utilizando o formulário - web. + Finalmente, se o envio for demorado, prepare o trabalho off-line para que nada seja perdido se houver um problema ao enviá-lo.
    -
    - Anexando <literal>patches</literal> ou arquivos +
    + Anexando Patches ou Arquivos - As instruções abaixo se aplicam ao envio - de PRs por email: + Ao anexar um patch, certifique-se de usar com diff1 para criar ou unificar o diff e certificar-se de especificar os números de revisão exatos do SVN dos arquivos que você modificou para que os desenvolvedores que lerem seu relatório possam aplicá-los facilmente. Para problemas com o kernel ou com os utilitários de base, um patch para o FreeBSD-CURRENT (a branch HEAD do Subversion) é o preferido, já que todo código novo deve ser aplicado e testado lá primeiro. Após testes apropriados ou substanciais terem sido feitos, o código será mesclado/migrado para a branch FreeBSD-STABLE. - O programa &man.send-pr.1; tem a capacidade de anexar - arquivos em um relatório de problemas. Você - pode anexar quantos arquivos desejar desde que os mesmos - possuam nomes únicos (i.e. o nome próprio do - arquivo, sem o caminho de diretório). Basta usar a - opção na linha de comando - para anexar os arquivos desejados: + Se você anexar um patch inline, em vez de um anexo, observe que o problema mais comum, de longe, é a tendência de alguns programas de email renderizar tabs como espaços, o que ira arruinar completamente qualquer coisa destinada a fazer parte de um Makefile. -&prompt.user; send-pr -a /var/run/dmesg -a /tmp/errors + Não envie correções como anexos usando Content-Transfer-Encoding: quoted-printable. Isso irá escapar os caracteres e todo o patch se tornará inútil. - Não se preocupe com os arquivos binários, - eles serão encodados automaticamente de forma a - não perturbar o seu agente de correio. + Observe também que, embora a inclusão de pequenos patches em um PR geralmente esteja correto - particularmente quando eles corrigem o problema descrito no PR - patches grandes e especialmente códigos novos que podem exigir uma revisão substancial antes do commit, deveriam ser colocados em um servidor web ou FTP, e a URL deveria ser incluída no PR em vez do patch. Patches por e-mail tendem a ficar embaralhados, e quanto maior o patch, mais difícil será para as partes interessadas recuperá-lo. Além disso, postar um patch na web permite modificá-lo sem ter que reenviar todo o patch em um followup do PR original. Finalmente, os patches grandes simplesmente aumentam o tamanho do banco de dados, uma vez que os PRs fechados não são realmente excluídos, mas sim mantidos e simplesmente marcados como completos. - Se você anexar um patch, tenha - certeza de utilizar a opção - ou no &man.diff.1; para criar um diff - contextual ou um diff unificado (o formato unificado é - preferido), e tenha certeza de especificar os números - de revisão exatos dos arquivos que você - modificou, desta forma o desenvolvedor que ler seu - relatório terá condições de - aplicá-los facilmente. Para problemas com o kernel ou - com os aplicativos do sistema base, um - patch para o &os.current; (o ramo HEAD do - CVS) é preferido uma vez que todo novo código - deve ser aplicado e testado primeiro nele. Depois que forem - realizados os testes apropriados, o código será - fundido ou migrado para o ramo &os.stable;. - - Se você juntar um patch - no corpo do email, em vez de enviá-lo como um - arquivo anexo, você estará sujeito a - ocorrência de um problema bastante comum ocasionado - pela tendência de alguns clientes de email de converter - tabs em espaços, o que irá arruinar - completamente qualquer coisa que você tenha enviado - com intenção de que fosse parte de um - Makefile. - - Não envie patches como anexos - usando Content-Transfer-Encoding: quoted-printable - . Isto irá realizar - character escaping e o - patch inteiro estará - inutilizado. - - Observe também que incluir pequenos - patches em um PR é normalmente a - coisa certa a se fazer — particularmente quando ele - corrige o problema descrito no PR — grandes - patches e especialmente código novo, - que normalmente requerem uma revisão substancial antes - de serem incorporados, devem ser colocados em um servidor web - ou de FTP, e a url deve ser incluída no PR ao - invés do patch propriamente dito. - Os patches dentro de um email tendem a se - deformar, especialmente quando o GNATS está envolvido, - e quanto maior o patch, maior é a dificuldade para - ambas as partes em consertá-lo. Além de que, ao - colocar o patch na web, você pode - modificá-lo sem ter que reenviar o arquivo completo - como um followup do PR original. - Além disso, os grandes patches - simplesmente aumentam o tamanho do banco de dados, uma vez que - os relatórios de problema fechados não - são deletados, continuando a existir marcados como - closed. - - Você deve observar que a menos que - especifique explicitamente no seu PR ou diretamente no seu - patch, qualquer correção que você envie - será considerada como estando licenciada sob os mesmos - termos do arquivo original que você modificou. + Você também deve observar que, a menos que você especifique explicitamente o contrário em seu PR ou no próprio patch, quaisquer patches enviados por você serão considerados licenciados sob os mesmos termos do arquivo original que você modificou.
    -
    - Preenchendo o template +
    + Preenchendo o Modelo - As instruções abaixo se aplicam apenas ao - envio de PRs por email: + Somente no modelo de e-mail, você encontrará os seguintes campos de uma única linha: - Quando você executar o programa &man.send-pr.1;, - você será apresentado a um template. O template - consiste em uma lista de campos, alguns dos quais - estarão pré-preenchidos, e alguns irão - possuir comentários explicando o seu propósito - ou então listando os valores aceitáveis. - Não se preocupe com os comentários, eles - serão removidos automaticamente se você - não modificá-los ou então os remova - você mesmo. - - Na parte superior do template, logo abaixo das linhas - SEND-PR:, está o cabeçalho do - email. Você normalmente não necessita - modificá-lo, a menos que você esteja enviando o - relatório de problema a partir de uma máquina ou - de uma conta a qual pode enviar, mas não pode receber - emails, neste caso você deve configurar manualmente os - campos From: e Reply-To: - para o seu endereço de email real. Você - também pode querer enviar uma cópia do - relatório para você mesmo (ou para alguma outra - pessoa) através do uso de uma cópia carbono, - adicionando um ou mais endereços de email na linha de - cabeçalho Cc:. - - Os campos de linha única descritos abaixo, - estão disponíveis apenas no template do - email: - - Submitter-Id: Não altere - este campo. O valor padrão é - current-users e está correto, - mesmo se você estiver executando o - &os.stable;. + Submeter-Id (ID do remetente): Não altere isso. O valor padrão de current-users está correto, mesmo se você estiver usando o FreeBSD-STABLE. - Confidential: Não altere - este campo. O valor padrão é - no. Não tem sentido - alterá-lo já que não existem - relatórios de problema confidenciais no &os; - — o banco de dados de PR é - distribuído mundialmente pelo - CVSup. + Confidential (Confidencial): Isto é pré-preenchido como no. Alterá-lo não faz sentido, já que não existe um relatório confidencial de problemas do FreeBSD - o banco de dados de PR é distribuído para todo mundo. - Severity: Escolha uma - opção entre non-critical, - serious ou critical. - Não faça escândalo; abstenha-se de - rotular seu problema como critical a - menos que ele realmente seja (por ex. questões de - corrupção de dados, grave retrocesso de - funcionalidade no -CURRENT em relação a - versão anterior, etc)ou de - serious a menos que seja algo que vai - afetar muitos usuários (Kernel panic ou travamentos - do sistema; Problemas com algum driver de dispositivo em - particular ou com utilitários de sistema). Os - desenvolvedores do &os; não irão - necessariamente trabalhar no seu problema mais - rápido se você inflar sua importância - uma vez que existem muitas outras pessoas que fizeram - exatamente isso — na verdade, alguns desenvolvedores - prestam pouca atenção a este campo por causa - disso. + Severety (Gravidade): Um dos non-critical (não críticos), serious (sério) ou critical (crítico). Não exagere; abstenha-se de rotular seu problema como critical a menos que realmente seja (por exemplo, problemas de corrupção de dados, séria regressão da funcionalidade anterior no -CURRENT) ou serious a menos que seja algo que afetará muitos usuários (kernel entra em pane ou congela; problemas com determinados drivers de dispositivo ou utilitários do sistema). Os desenvolvedores do FreeBSD não irão necessariamente trabalhar no seu problema mais rapido se você inflar sua importância, já que há tantas outras pessoas que fizeram exatamente isso - na verdade, alguns desenvolvedores dão pouca atenção a esse campo por causa disso. + - - Problemas de segurança - não devem ser submetidos - para o GNATS, pois todas as informações - no GNATS são de conhecimento público. - Por favor, envie estes problemas seguindo as nossas - diretrizes - sobre relatórios de segurança. - - - - *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Wed Sep 12 02:22:31 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F270510A670F; Wed, 12 Sep 2018 02:22:30 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A4EA1950C5; Wed, 12 Sep 2018 02:22:30 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9F85C205B4; Wed, 12 Sep 2018 02:22:30 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8C2MU53037917; Wed, 12 Sep 2018 02:22:30 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8C2MUuM037899; Wed, 12 Sep 2018 02:22:30 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809120222.w8C2MUuM037899@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Wed, 12 Sep 2018 02:22:30 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52249 - head/pt_BR.ISO8859-1/articles/freebsd-update-server X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: head/pt_BR.ISO8859-1/articles/freebsd-update-server X-SVN-Commit-Revision: 52249 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 02:22:31 -0000 Author: ebrandi Date: Wed Sep 12 02:22:29 2018 New Revision: 52249 URL: https://svnweb.freebsd.org/changeset/doc/52249 Log: pt_BR.ISO8859-1/articles/freebsd-update-server: converted to .po * content synchronized with en_US document (rev 51862) * article.xml converted to .po * .po file was translated to pt_BR * pt_BR.po and article.xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/freebsd-update-server/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/freebsd-update-server/article.xml (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/freebsd-update-server/article.xml ============================================================================== --- head/pt_BR.ISO8859-1/articles/freebsd-update-server/article.xml Wed Sep 12 02:10:25 2018 (r52248) +++ head/pt_BR.ISO8859-1/articles/freebsd-update-server/article.xml Wed Sep 12 02:22:29 2018 (r52249) @@ -1,142 +1,89 @@ - -Servidor de Atualização do FreeBSD"> + +FreeBSD + Update Server"> ]> - -
    - Construa Seu Próprio Servidor de Atualização do &os; - + Jason Helfman
    Jason Helfman jgh@FreeBSD.org
     - JasonHelfman -
    &a.jgh;
    -     + 2009 2010 2011 2013 Jason Helfman - - 2009 - 2010 - 2011 - 2013 - Jason Helfman - - - &tm-attrib.freebsd; - &tm-attrib.general; - &tm-attrib.intel; - &tm-attrib.amd; + FreeBSD is a registered trademark of the FreeBSD Foundation. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the â„¢ or the ® symbol. + Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. + AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc. $FreeBSD$ $FreeBSD$ - - Este artigo descreve como construir um &fbus.ap; para uso - interno na sua organização. O software freebsd-update-server - foi escrito pelo &a.cperciva;, Chefe de Segurança emérito do - &os;. Para usuários que acreditam que é conveniente atualizar - seus sistemas a partir de um servidor oficial de atualização, - construir o seu próprio &fbus.ap; pode ajudá-lo a estender suas - funcionalidades, seja por adicionar suporte a versões - customizadas do &os; ou por viabilizar a criação de um servidor - local o qual permitirá atualizações mais rápidas caso você - possua muitos servidores para atualizar. - + + Este artigo descreve a construção de um servidor de atualizações do FreeBSD interno. O freebsd-update-server foi escrito por Colin Percival cperciva@FreeBSD.org, Oficial de Segurança Emérito do FreeBSD. Para usuários que acham conveniente atualizar seus sistemas em um servidor de atualização oficial, construir seu próprio FreeBSD Update Server pode ajudar a estender sua funcionalidade suportando versões do FreeBSD ajustadas manualmente ou fornecendo um espelho local que permitirá atualizações mais rápidas para várias máquinas. +     Agradecimentos - Este artigo posteriormente impresso na BSD - Magazine. + + Este artigo foi publicado posteriormente no BSD Magazine. - Introdução + Introdução - Usuários experientes ou administradores são frequentemente - responsáveis por diversas máquinas ou ambientes. Eles entendem - as dificuldades e os desafios de manter tal estrutura. A - utilização de um &fbus.ap; torna mais fácil a tarefa de - implantar patches de segurança e de softwares nas máquinas - selecionadas para testá-los antes proceder com o seu deploy no - ambiente de produção. Isto também significa que seus servidores - poderão ser atualizados a partir da rede local em vez de - utilizarem sua conexão de internet, o que torna o processo muito - mais rápido. Este artigo descreve as etapas envolvidas na - criação de um &fbus.ap; para uso interno. + Usuários experientes ou administradores são muitas vezes responsáveis por várias máquinas ou ambientes. Eles entendem as difíceis demandas e desafios da manutenção de tal infraestrutura. A execução de um Servidor de Atualização do FreeBSD facilita a implantação de patches de segurança e software em máquinas de teste selecionadas antes de implementá-las nas maquinas em produção. Isso também significa que vários sistemas podem ser atualizados a partir da rede local, em vez de uma conexão de Internet potencialmente mais lenta. Este artigo descreve os passos envolvidos na criação de um Servidor de Atualização do FreeBSD interno. - Pré-Requisitos + Pré-requisitos - Para construir o seu &fbus.ap; alguns requisitos devem ser - cumpridos. + Para construir um Servidor de Atualização do FreeBSD interno, alguns requisitos devem ser atendidos. - Estar executando o &os;. + Um sistema FreeBSD em execução. - No mínimo, as atualizações precisam ser compiladas em - uma versão do &os; maior ou igual a versão alvo a ser - distribuída. + No mínimo, as atualizações requerem a criação de uma versão do FreeBSD maior ou igual a versão do release alvo para a distribuição. - Ter acesso a uma conta de usuário com no mínimo - 4 GB de espaço livre. Isto permite a criação de - atualizações para as versões 7.1 e 7.2, mas o espaço exato - requerido pode mudar de versão para versão. + Uma conta de usuário com pelo menos 4 GB de espaço disponível. Isso permitirá a criação de atualizações para 7.1 e 7.2, mas os requisitos de espaço exatos podem mudar de versão para versão. - Ter acesso a uma conta &man.ssh.1; em uma máquina - remota para enviar as atualizações a serem - distribuídas. + Uma conta com acesso ao ssh1 em uma máquina remota para carregar atualizações distribuídas. - Possuir um servidor web, como Apache, - com mais da metade do espaço necessário para a compialação. - Por exemplo, compilações testes para 7.1 e 7.2 consomem um - espaço total de 4 GB, e usam 2.6 GB para - distribuir essas atualizações. + Um servidor web, como o Apache, com mais da metade do espaço necessário para a construção. Por exemplo, as compilações de teste para 7.1 e 7.2 consomem uma quantidade total de 4 GB e o espaço do servidor da web necessário para distribuir essas atualizações é de 2.6 GB. - Ter conhecimento básico de shell script com o Bourne - shell, &man.sh.1; + Conhecimento básico de shell script com o Bourne shell, sh1. - Instalação & Configuração + Configuração: Instalação & Configuração - Para efetuar o download do software freebsd-update-server - instale o devel/subversion e - execute: + Faça o download do software freebsd-update-server instalando devel/subversion e security/ca_root_nss, e execute: - &prompt.user; svn co http://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server - - Atualize o scripts/build.conf de forma - adequada. Ele é usado durante as operações de - compilação. + % svn co https://svn.freebsd.org/base/user/cperciva/freebsd-update-build freebsd-update-server - Aqui está o build.conf padrão, que - deverá ser modificado para se adequar ao seu ambiente. + Atualize o scripts/build.conf apropriadamente. Ele é criado durante todas as operações de construção. - - + Aqui está o build.conf padrão, que deve ser modificado para se adequar ao seu ambiente. -# Main configuration file for FreeBSD Update builds. The + + # Main configuration file for FreeBSD Update builds. The # release-specific configuration data is lower down in # the scripts tree. @@ -159,83 +106,52 @@ MASTERACCT=builder@wadham.daemonology.net - Parâmentros que devem ser considerados: + Parâmetros para consideração seriam: - Este é o local de onde serão feitos os downloads das - imagens ISO (pela sub-rotina fetchiso() - do scripts/build.subr). O local a ser - configurado não é limitado a URIs de FTP. Qualquer URI - suportada pela ferramenta &man.fetch.1; pode ser - usada. + Este é o local onde as imagens ISO são baixadas (pela sub-rotina fetchiso() do scripts/build.subr). A localização configurada não está limitada a URIs de FTP. Qualquer esquema de URI suportado pelo utilitário padrão fetch deve funcionar bem. - Customizações do código da - fetchiso() podem ser feitas copiando - o script padrão build.subr para o - local da sua versão e arquitetura específica - scripts/RELEASE/ARCHITECTURE/build.subr e - alterando o arquivo. + Personalizações para o código de fetchiso() podem ser instaladas copiando o script padrão build.subr para a área específica do release e da arquitetura em scripts/RELEASE/ARCHITECTURE/build.subr e aplicando alterações locais. - O nome do computador que fará a compilação. Esta - informação será exibida durante a atualização dos - sistemas: + O nome do host em construção. Esta informação será exibida em sistemas atualizados ao executar: - &prompt.user; uname -v + % uname -v - A chave SSH para enviar os - arquivos para o servidor de atualização. O par de chaves - pode ser criado digitando ssh-keygen -t - dsa. Este parâmetro é opcional; a autenticação - por senha será usada como método de autenticação quando a - variável SSHKEY não estiver - definida. + A chave SSH para fazer upload de arquivos para o servidor de atualizações. Um par de chaves pode ser criado digitando ssh-keygen -t dsa. Este parâmetro é opcional; a autenticação de senha padrão será usada como um método de autenticação secundário quando a SSHKEY não estiver definida. - A página do manual &man.ssh-keygen.1; tem informações - mais detalhadas sobre o SSH e os - passos apropriados para criar e usar chaves. + A página de manual do ssh-keygen 1 contém informações mais detalhadas sobre o SSH e as etapas apropriadas para criar e usar um. - Conta para enviar os arquivos para o servidor de - atualização. + Conta para fazer upload de arquivos para o servidor de atualização. - Diretório do servidor de atualização para o qual os - arquivos serão enviados. + Diretório no servidor de atualização para o qual os arquivos são enviados. - O arquivo build.conf padrão, distribuído - com o fonte do freebsd-update-server, - está preparado para compilar a versão &arch.i386; do &os;. - A titulo de exemplo sobre como compilar um servidor de - atualização para outras arquiteturas, as seguintes modificações - são necessárias para a arquitetura &arch.amd64;: + O arquivo padrão build.conf fornecido com o código-fonte do freebsd-update-server é adequado para a criação de versões i386 do FreeBSD. Como um exemplo de criação de um servidor de atualização para outras arquiteturas, as etapas a seguir descrevem as alterações necessárias na configuração para o amd64: - Crie um ambiente de compilação para o - &arch.amd64;: + Crie um ambiente de compilação para o amd64: - &prompt.user; mkdir -p /usr/local/freebsd-update-server/scripts/7.2-RELEASE/amd64 + % mkdir -p /usr/local/freebsd-update-server/scripts/7.2-RELEASE/amd64 - Copie o arquivo build.conf para o - diretório recém criado. As configurações de compilação para - o &os; 7.2-RELEASE na arquitetura &arch.amd64; devem ser - similares a: + Instale um build.conf no diretório de criação recém-criado. As opções de configuração de compilação para o FreeBSD 7.2-RELEASE com arquitetura amd64 devem ser semelhantes a: - # SHA256 hash of RELEASE disc1.iso image. + # SHA256 hash of RELEASE disc1.iso image. export RELH=1ea1f6f652d7c5f5eab7ef9f8edbed50cb664b08ed761850f95f48e86cc71ef5 # Components of the world, source, and kernels @@ -251,19 +167,13 @@ export EOL=1275289200 - A chave hash &man.sha256.1; da versão desejada, - ela é publicada no anúncio da versão. + A chave sha2561 usada para fazer o hash para a release desejada é publicada no respectivo anúncio de release. - Para gerar o número "End of Life" (Fim da Vida) para - o build.conf, consulte a informação - sobre o "Estimated EOL" publicada no Site de - Segurança do &os;. O valor do - EOL pode ser derivado a partir da - data listada no site, usando a ferramenta &man.date.1;, - por exemplo: - &prompt.user; date -j -f '%Y%m%d-%H%M%S' '20090401-000000' '+%s' + Para gerar o número "End of Life" para o build.conf, consulte o "EOL estimado" publicado no Site de Segurança do FreeBSD. O valor de EOL pode ser derivado da data listada no site, usando o utilitário date1, por exemplo: + + % date -j -f '%Y%m%d-%H%M%S' '20090401-000000' '+%s' @@ -271,16 +181,11 @@ export EOL=1275289200 - Preparando a atualização + Compilando o Código de Atualização - O primeiro passo é executar o - scripts/make.sh. Isto irá compilar alguns - binários, criar diretórios, e gerar uma chave de assinatura - RSA usada para aprovar as compilações. Neste passo, uma senha - deverá ser fornecida para terminar a criação da chave de - assinatura. + O primeiro passo é executar o scripts/make.sh. Isso criará alguns binários, criará diretórios e irá gerar uma chave de assinatura RSA usada para aprovar as compilações. Nesta etapa, uma senha terá que ser fornecida para a criação final da chave de assinatura. - &prompt.root; sh scripts/make.sh + # sh scripts/make.sh cc -O2 -fno-strict-aliasing -pipe findstamps.c -o findstamps findstamps.c: In function 'usage': findstamps.c:45: warning: incompatible implicit declaration of built-in function 'exit' @@ -301,24 +206,19 @@ enter aes-256-cbc encryption password: Verifying - enter aes-256-cbc encryption password: - Anote a impressão digital (fingerprint) da chave gerada. - Ela é necessária no - /etc/freebsd-update.conf para as - atualizações de binários. + Mantenha um backup do fingerprint gerado. Este valor é necessário para o arquivo /etc/freebsd-update.conf para as atualizações binárias. - Neste ponto, nós estamos prontos para a etapa de - compilação. + Neste ponto, estamos prontos para montar uma construção. - &prompt.root; cd /usr/local/freebsd-update-server -&prompt.root; sh scripts/init.sh amd64 7.2-RELEASE + # cd /usr/local/freebsd-update-server +# sh scripts/init.sh amd64 7.2-RELEASE - A seguir está um exemplo de uma execução - inicial. + O que se segue é uma amostra de uma execução da compilaçãoinicial. - &prompt.root; sh scripts/init.sh amd64 7.2-RELEASE + # sh scripts/init.sh amd64 7.2-RELEASE Mon Aug 24 16:04:36 PDT 2009 Starting fetch for FreeBSD/amd64 7.2-RELEASE /usr/local/freebsd-update-server/work/7.2-RELE100% of 588 MB 359 kBps 00m00s Mon Aug 24 16:32:38 PDT 2009 Verifying disc1 hash for FreeBSD/amd64 7.2-RELEASE @@ -357,22 +257,10 @@ world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... - Em seguida, a compilação da base do sistema será feita - novamente, com os patches. Uma explicação mais detalhada pode - ser encontrada em scripts/build.subr. + Então a compilação do world é executada novamente, com patches para world. Uma explicação mais detalhada pode ser encontrada em scripts/build.subr. - Durante a segunda compilação, o serviço de network time - protocol, &man.ntpd.8; será desligado. De acordo com - &a.cperciva;, Chefe de Segurança emérito do &os;, "o freebsd-update-server - compila códigos necessários para identificar os - timestamps, os quais são armazenadas em - arquivos, de modo que estes últimos podem ser ignorados quando - estivermos comparando compilações diferentes para determinar - quais arquivos precisam ser atualizados. Esta procura por - timestamp funciona realizando duas - compilações separadas por 400 dias e comparando os - resultados." + Durante este segundo ciclo de compilação, o daemon do protocolo de tempo de rede, ntpd8, é desativado. Segundo o Colin Percival cperciva@FreeBSD.org, Oficial de segurança emérito do FreeBSD, "a compilação do código do freebsd-update-server precisa identificar os timestamps que são armazenados nos arquivos para que possam ser ignorados ao comparar builds para determinar quais arquivos precisam ser atualizados. Essa busca de timestamp trabalha com duas construções com 400 dias de diferença e compara os resultados." Mon Aug 24 17:54:07 PDT 2009 Extracting world+src for FreeBSD/amd64 7.2-RELEASE @@ -409,7 +297,7 @@ world|base|/usr/lib/libalias_dummy.a world|base|/usr/lib/libalias_ftp.a ... - Finalmente, a compilação termina. + Finalmente, a construção é concluída. Values of build stamps, excluding library archive headers: v1.2 (Aug 25 2009 00:40:36) @@ -444,162 +332,127 @@ they look sensible, then run # sh -e approve.sh amd64 7.2-RELEASE to sign the release. - Se tudo estiver correto, aprove a compilação. Maiores - informações sobre como determinar se o processo finalizou com - sucesso podem ser encontradas no arquivo chamado - USAGE, distribuído com o código fonte. - Execute o scripts/approve.sh. Isto irá - assinar a versão, e mover os seus componentes para uma área de - preparo adequada para a transferência para o servidor de - distribuição. + Aprove a compilação se tudo estiver correto. Mais informações sobre como determinar isso podem ser encontradas no arquivo fonte distribuído chamado USAGE. Execute scripts/approve.sh, conforme indicado. Isso assinará a release e moverá os componentes para uma área de preparação adequada para o upload. - &prompt.root; cd /usr/local/freebsd-update-server -&prompt.root; sh scripts/mountkey.sh + # cd /usr/local/freebsd-update-server +# sh scripts/mountkey.sh - &prompt.root; sh -e scripts/approve.sh amd64 7.2-RELEASE + # sh -e scripts/approve.sh amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to patch source directories for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:07 PDT 2009 Updating databases for FreeBSD/amd64 7.2-RELEASE Wed Aug 26 12:50:07 PDT 2009 Cleaning staging area for FreeBSD/amd64 7.2-RELEASE - Depois que o processo de aprovação tiver sido finalizado, - o processo de transferência pode ser iniciado. + Após o processo de aprovação ser concluído, o procedimento de upload pode ser iniciado. - &prompt.root; cd /usr/local/freebsd-update-server -&prompt.root; sh scripts/upload.sh amd64 7.2-RELEASE + # cd /usr/local/freebsd-update-server +# sh scripts/upload.sh amd64 7.2-RELEASE - No caso do código de atualização precisar ser transferido - novamente para o servidor de distribuição, isto poderá ser - feito entrando-se no diretório público de distribuição da - versão desejada e atualizando os atributos do arquivo - uploaded. + No caso de o código de atualização precisar ser reenviado, isso pode ser feito mudando para o diretório de distribuições públicas para o release alvo e atualizando os atributos do arquivo carregado. - &prompt.root; cd /usr/local/freebsd-update-server/pub/7.2-RELEASE/amd64 -&prompt.root; touch -t 200801010101.01 uploaded + # cd /usr/local/freebsd-update-server/pub/7.2-RELEASE/amd64 +# touch -t 200801010101.01 uploaded - Os arquivos transferidos precisam ficar na raiz do servidor - web para que as atualizações sejam distribuídas. A exata - configuração dependerá do servidor web utilizado. Para o - servidor web Apache, por favor, - consulte a seção Configuração do - servidor Apache do Handbook. + - Atualize o KeyPrint e o - ServerName no arquivo - /etc/freebsd-update.conf, e efetue as - atualizações de acordo com os procedimentos descritos na seção - Atualização - do &os; do Handbook. + + Os arquivos enviados precisarão estar no diretório de documentos raiz do servidor web para que as atualizações sejam distribuídas. A configuração exata irá variar dependendo do servidor web usado. Para o servidor web Apache, consulte a sessão Configuração de servidores Apache no Handbook. + + + + + + + + Atualize o KeyPrint e ServerName do cliente no arquivo /etc/freebsd-update.conf, e execute as atualizações conforme instruído na Seção de Atualização do FreeBSD no Handbook. + + + - Para o &fbus.ap; funcionar corretamente, é preciso que - estejam compiladas a versão atual e - a versão alvo para a qual você deseja - se atualizar. Isto é necessário para que o sistema determine - quais são os arquivos que diferem entre as versões. Por - exemplo, para atualizar o &os; da versão 7.1-RELEASE - para a versão 7.2-RELEASE, será necessário que você compile e - transfira os arquivos de ambas as versões para o seu servidor - de atualização. + Para que o Servidor de Atualização do FreeBSD funcione corretamente, atualizações para ambas releases atual e a release que se deseja atualizar precisam ser compilados. Isso é necessário para determinar as diferenças de arquivos entre as releases. Por exemplo, ao atualizar um sistema FreeBSD de 7.1-RELEASE para 7.2-RELEASE, as atualizações precisarão ser construídas e carregadas em seu servidor de distribuição para ambas as versões. - Para referência, segue um exemplo de log completo da - execução do - init.sh - . + Para referência, toda a execução do init.sh é anexada. - Compilando um patch + Compilando um Patch - Toda vez que um aviso de segurança - ou uma nota de - segurança é anunciada, uma atualização pode ser - compilada. + Toda vez que é anunciado um aviso de segurança ou uma notificação de segurança, um patch de atualização pode ser construído. - Para este exemplo, a versão 7.1-RELEASE será usada. + Para este exemplo, o 7.1-RELEASE será usado. - Algumas suposições são feitas para a compilação de uma - versão diferente: + Algumas suposições são feitas para uma versão diferente: - Crie a estrutura correta de diretório para a compilação - inicial. + Configure a estrutura de diretórios correta para a compilação inicial. - Faça a compilação inicial da 7.1-RELEASE + Execute uma compilação inicial para o 7.1-RELEASE. - Crie o diretório do patch para a respectiva versão em - /usr/local/freebsd-update-server/patches/. + Crie o diretório de correção do respectivo release no diretório /usr/local/freebsd-update-server/patches/. - &prompt.user; mkdir -p /usr/local/freebsd-update-server/patches/7.1-RELEASE/ -&prompt.user; cd /usr/local/freebsd-update-server/patches/7.1-RELEASE + % mkdir -p /usr/local/freebsd-update-server/patches/7.1-RELEASE/ +% cd /usr/local/freebsd-update-server/patches/7.1-RELEASE - Como exemplo, pegue o patch para o &man.named.8;. Leia o - aviso, obtenha o arquivo necessário do Aviso de Segurança - do &os;. Mais informações sobre como interpretar os - avisos, podem ser encontradas no Handbook do - &os;. + Como exemplo, pegue o patch para named8. Leia o comunicado, e pegue o arquivo necessário de Avisos de Segurança do FreeBSD . Mais informações sobre a interpretação do comunicado podem ser encontradas no Handbook do FreeBSD. - Na nota de segurança, - este aviso é chamado de SA-09:12.bind. - Depois de fazer o download do arquivo, é necessário renomeá-lo - para o nível correto do patch. É recomendado manter - consistência com os níveis oficiais de patch do &os;, mas o nome - pode ser escolhido livremente. Para esta compilação, vamos - seguir a prática atual do &os; e chamá-lo de - p7. Renomeie o arquivo: + No resumo de segurança, este comunicado é chamado SA-09:12.bind. Depois de baixar o arquivo, é necessário renomear o arquivo para um nível de correção apropriado. Sugere-se manter isso consistente com os níveis oficiais de correção do FreeBSD, mas seu nome pode ser escolhido livremente. Para esta compilação, vamos seguir a prática atualmente estabelecida do FreeBSD e chamar isso de p7. Renomeie o arquivo: - &prompt.user; cd /usr/local/freebsd-update-server/patches/7.1-RELEASE/; mv bind.patch 7-SA-09:12.bind + % cd /usr/local/freebsd-update-server/patches/7.1-RELEASE/; mv bind.patch 7-SA-09:12.bind - Ao executar uma compilação de nível de patch, é - assumido que os patches anteriores estarão no mesmo lugar. - Quando uma compilação de patch é executada, ela vai aplicar - todos os patches contidos no diretório do patch. + Ao executar uma compilação em nível de patch, supõe-se que os patches anteriores estejam no lugar. Quando uma compilação de patch é executada, ela executará todas os patches contidos no diretório de patch. - Podem ser adicionados patches personalizados na - Compilação. Use o número zero, ou qualquer outro - número. + Pode haver patches personalizados adicionados a qualquer compilação. Use o número zero ou qualquer outro número. - É da responsabilidade do administrador do &fbus.ap; - tomar as devidas ações para verificar a autenticidade de cada - patch. + Cabe ao administrador do Servidor de Atualização do FreeBSD tomar as medidas apropriadas para verificar a autenticidade de cada patch. - Neste ponto, um diff está pronto para - ser construído. O software primeiro irá verificar se o - scripts/init.sh foi executado na respectiva - versão antes de executar a construção do diff. + Neste ponto, um diff está pronto para ser construído. O software verifica primeiro para ver se um scripts/init.sh foi executado na respectiva versão antes de executar a construção do diff. - &prompt.root; cd /usr/local/freebsd-update-server -&prompt.root; sh scripts/diff.sh amd64 7.1-RELEASE 7 + # cd /usr/local/freebsd-update-server +# sh scripts/diff.sh amd64 7.1-RELEASE 7 - O que segue abaixo é um exemplo do log da execução de uma - compilação diferencial. + O que se segue é um exemplo de uma execução de uma compilação diferencial. - &prompt.root; sh -e scripts/diff.sh amd64 7.1-RELEASE 7 + # sh -e scripts/diff.sh amd64 7.1-RELEASE 7 Wed Aug 26 10:09:59 PDT 2009 Extracting world+src for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 17:10:25 UTC 2009 Building world for FreeBSD/amd64 7.1-RELEASE-p7 Wed Aug 26 18:05:11 UTC 2009 Distributing world for FreeBSD/amd64 7.1-RELEASE-p7 @@ -671,8 +524,7 @@ Wed Aug 26 17:55:02 UTC 2009 Wed Aug 26 17:20:39 UTC 2009 ... - As atualizações são exibidas, e uma aprovação é - requisitada. + As atualizações são impressas e a aprovação é solicitada. New updates: kernel|generic|/GENERIC/kernel.symbols|f|0|0|0555|0|7c8dc176763f96ced0a57fc04e7c1b8d793f27e006dd13e0b499e1474ac47e10| @@ -691,10 +543,9 @@ files to confirm that they look sensible, then run # sh -e approve.sh amd64 7.1-RELEASE to sign the build. - Siga o mesmo processo descrito anteriormente para aprovar a - compilação: + Siga o mesmo processo descrito anteriormente para aprovar uma compilação: - &prompt.root; sh -e scripts/approve.sh amd64 7.1-RELEASE + # sh -e scripts/approve.sh amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Signing build for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to patch source directories for FreeBSD/amd64 7.1-RELEASE Wed Aug 26 12:50:06 PDT 2009 Copying files to upload staging area for FreeBSD/amd64 7.1-RELEASE @@ -707,85 +558,71 @@ ready to be uploaded. Remember to run to unmount the decrypted key once you have finished signing all the new builds. - Depois de aprovar a compilação, faça a transferência do - software para o servidor de distribuição: + Depois de aprovar a compilação, faça o upload do software: - &prompt.root; cd /usr/local/freebsd-update-server -&prompt.root; sh scripts/upload.sh amd64 7.1-RELEASE + # cd /usr/local/freebsd-update-server +# sh scripts/upload.sh amd64 7.1-RELEASE - Para referência, segue o log de uma execução completa do - diff.sh. + Para referência, toda a execução do diff.sh é anexada. Dicas + + + + + - Se uma versão personalizada tiver sido compilada usando - o procedimento - nativo do make release, o código do - freebsd-update-server irá - funcionar a partir da sua versão. Por exemplo, uma versão - sem o ports ou sem a documentação pode ser compilada - limpando-se as funcionalidades pertencentes às sub-rotinas - de documentação findextradocs(), - addextradocs() e alterando o local de - download na fetchiso(), - respectivamente, no scripts/build.subr. - Em um último passo, mude o hash &man.sha256.1; em - build.conf na sua respectiva versão e - arquitetura e então você está pronto para compilar sua - versão personalizada. + Se uma versão personalizada for criada usando o procedimento make release nativo, o freebsd-update-server funcionará a partir do seu release. Como exemplo, uma versão sem ports ou documentação pode ser construída limpando funcionalidades de limpeza pertinentes às sub-rotinas de documentação findextradocs(), addextradocs() e alterando o local de download em fetchiso(), respectivamente, em scripts/build.subr. Como último passo, altere o hash sha2561 no arquivo build.conf sob sua respectiva versão e arquitetura e você estará pronto para criar sua versão personalizada. - # Compare ${WORKDIR}/release and ${WORKDIR}/$1, identify which parts + # Compare ${WORKDIR}/release and ${WORKDIR}/$1, identify which parts # of the world|doc subcomponent are missing from the latter, and # build a tarball out of them. findextradocs () { } # Add extra docs to ${WORKDIR}/$1 -addextradocs () { -} - +addextradocs () { +} - Adicionando a opção nas etapas - buildworld e - obj no script - scripts/build.subr pode acelerar o - processo dependendo do hardware usado, entretanto isto não é - necessário. Usar esta opção em outras etapas não é - recomendado, pois pode fazer a compilação ficar - instável. + Adicionando flags para os alvos buildworld e obj no script scripts/build.subr pode acelerar o processamento, dependendo do hardware usado, no entanto, não é necessário. O uso dessas flags em outros alvos não é recomendado, pois pode tornar a construção não confiável. - #Build the world -log "Building world" -cd /usr/src && -make -j 2 ${COMPATFLAGS} buildworld 2>&1 + # Build the world + log "Building world" + cd /usr/src && + make -j 2 ${COMPATFLAGS} buildworld 2>&1 -# Distribute the world -log "Distributing world" -cd /usr/src/release && -make -j 2 obj && - make ${COMPATFLAGS} release.1 release.2 2>&1 + # Distribute the world + log "Distributing world" + cd /usr/src/release && + make -j 2 obj && + make ${COMPATFLAGS} release.1 release.2 2>&1 - Crie uma entrada SRV apropriada no DNS - para o servidor de atualização, e coloque outros servidores - com pesos variados. Usar este recurso irá permitir que você - distribua a carga do processo de atualização entre vários - servidores, entretanto esta dica não será necessária a menos - que você deseje prover um serviço redundante. + Crie um registro DNS apropriado para o servidor de atualizações e coloque outros por trás dele com variáveis de pesos diferentes. O uso desse recurso fornecerá espelhos de atualização, no entanto, essa dica não é necessária, a menos que você deseje fornecer um serviço redundante. - - _http._tcp.update.myserver.com. IN SRV 0 2 80 host1.myserver.com. - SRV 0 1 80 host2.myserver.com. - SRV 0 0 80 host3.myserver.com. + _http._tcp.update.myserver.com. IN SRV 0 2 80 host1.myserver.com. + IN SRV 0 1 80 host2.myserver.com. + IN SRV 0 0 80 host3.myserver.com. Added: head/pt_BR.ISO8859-1/articles/freebsd-update-server/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/freebsd-update-server/pt_BR.po Wed Sep 12 02:22:29 2018 (r52249) @@ -0,0 +1,1583 @@ +# $FreeBSD$ +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Silvio Ap Silva , 2018. #zanata +# Jonas Ferreira , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-12 02:17+0000\n" +"PO-Revision-Date: 2018-09-12 01:09+0000\n" +"Last-Translator: Edson Brandi \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Jonas Ferreira, jonas.h.ferreira@me.com, 2018\n" +"Kanazuchi, contato@kanazuchi.com, 2018\n" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:8 +msgid "Build Your Own FreeBSD Update Server" +msgstr "Construa seu próprio servidor de atualização do FreeBSD" + +#. (itstool) path: affiliation/address +#: article.translate.xml:16 +#, no-wrap +msgid "Jason Helfman jgh@FreeBSD.org" +msgstr "Jason Helfman jgh@FreeBSD.org" + +#. (itstool) path: info/author +#: article.translate.xml:10 +msgid "" +" Jason Helfman <_:address-1/> " +msgstr "" +" Jason Helfman <_:address-1/> " + +#. (itstool) path: info/copyright +#: article.translate.xml:20 +msgid "" +"2009 2010 2011 2013 " +"Jason Helfman" +msgstr "" +"2009 2010 2011 2013 " +"Jason Helfman" + +#. (itstool) path: legalnotice/para +#: article.translate.xml:29 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:31 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the â„¢ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the â„¢ or the ® symbol." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:37 +msgid "" +"Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " +"and Xeon are trademarks or registered trademarks of Intel Corporation or its " +"subsidiaries in the United States and other countries." +msgstr "" +"Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " +"and Xeon are trademarks or registered trademarks of Intel Corporation or its " +"subsidiaries in the United States and other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:41 +msgid "" +"AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, " +"Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc." +msgstr "" +"AMD, AMD Athlon, AMD Opteron, AMD Phenom, AMD Sempron, AMD Turion, Athlon, " +"Élan, Opteron, and PCnet are trademarks of Advanced Micro Devices, Inc." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:46 article.translate.xml:48 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/freebsd-update-server/article.xml " +"51862 2018-06-17 16:40:13Z bcr $" +msgstr "" +"$FreeBSD: head/en_US.ISO8859-1/articles/freebsd-update-server/article.xml " +"51862 2018-06-17 16:40:13Z bcr $" + +#. (itstool) path: abstract/para +#: article.translate.xml:51 +msgid "" +"This article describes building an internal FreeBSD Update " +"Server. The freebsd-update-server is " +"written by Colin Percival cperciva@FreeBSD.org, Security " +"Officer Emeritus of FreeBSD. For users that think it is convenient to update " +"their systems against an official update server, building their own " +"FreeBSD Update Server may help to extend its " +"functionality by supporting manually-tweaked FreeBSD releases or by " +"providing a local mirror that will allow faster updates for a number of " +"machines." +msgstr "" +"Este artigo descreve a construção de um servidor de " +"atualizações do FreeBSD interno. O freebsd-update-" +"server foi escrito por Colin Percival cperciva@FreeBSD.org, Oficial de Segurança Emérito do FreeBSD. Para usuários que acham " +"conveniente atualizar seus sistemas em um servidor de atualização oficial, " +"construir seu próprio FreeBSD Update Server pode " +"ajudar a estender sua funcionalidade suportando versões do FreeBSD ajustadas " +"manualmente ou fornecendo um espelho local que permitirá atualizações mais " +"rápidas para várias máquinas." + +#. (itstool) path: sect1/title +#: article.translate.xml:66 +msgid "Acknowledgments" +msgstr "Agradecimentos" + +#. (itstool) path: sect1/para +#: article.translate.xml:68 +msgid "" +"This article was subsequently printed at BSD Magazine." +msgstr "" +"Este artigo foi publicado posteriormente no BSD Magazine." + +#. (itstool) path: sect1/title +#: article.translate.xml:73 +msgid "Introduction" +msgstr "Introdução" + +#. (itstool) path: sect1/para +#: article.translate.xml:75 +msgid "" +"Experienced users or administrators are often responsible for several " +"machines or environments. They understand the difficult demands and " +"challenges of maintaining such an infrastructure. Running a " +"FreeBSD Update Server makes it easier to deploy " +"security and software patches to selected test machines before rolling them " +"out to production. It also means a number of systems can be updated from the " +"local network rather than a potentially slower Internet connection. This " +"article outlines the steps involved in creating an internal " +"FreeBSD Update Server." +msgstr "" +"Usuários experientes ou administradores são muitas vezes responsáveis por " +"várias máquinas ou ambientes. Eles entendem as difíceis demandas e desafios " +"da manutenção de tal infraestrutura. A execução de um Servidor " +"de Atualização do FreeBSD facilita a implantação de patches de " +"segurança e software em máquinas de teste selecionadas antes de implementá-" +"las nas maquinas em produção. Isso também significa que vários sistemas " +"podem ser atualizados a partir da rede local, em vez de uma conexão de " +"Internet potencialmente mais lenta. Este artigo descreve os passos " +"envolvidos na criação de um Servidor de Atualização do FreeBSD " +" interno." + +#. (itstool) path: sect1/title +#: article.translate.xml:90 +msgid "Prerequisites" +msgstr "Pré-requisitos" + +#. (itstool) path: sect1/para +#: article.translate.xml:92 +msgid "" +"To build an internal FreeBSD Update Server some " +"requirements should be met." +msgstr "" +"Para construir um Servidor de Atualização do FreeBSD interno, alguns requisitos devem ser atendidos." + +#. (itstool) path: listitem/para +#: article.translate.xml:98 +msgid "A running FreeBSD system." +msgstr "Um sistema FreeBSD em execução." + +#. (itstool) path: note/para +#: article.translate.xml:101 +msgid "" +"At a minimum, updates require building on a FreeBSD release greater than or " +"equal to the target release version for distribution." +msgstr "" +"No mínimo, as atualizações requerem a criação de uma versão do FreeBSD maior " +"ou igual a versão do release alvo para a distribuição." + +#. (itstool) path: listitem/para +#: article.translate.xml:108 +msgid "" +"A user account with at least 4 GB of available space. This will allow the " +"creation of updates for 7.1 and 7.2, but the exact space requirements may " +"change from version to version." +msgstr "" +"Uma conta de usuário com pelo menos 4 GB de espaço disponível. Isso " +"permitirá a criação de atualizações para 7.1 e 7.2, mas os requisitos de " +"espaço exatos podem mudar de versão para versão." + +#. (itstool) path: listitem/para +#: article.translate.xml:115 +msgid "" +"An ssh1 account on a remote machine to upload distributed updates." +msgstr "" +"Uma conta com acesso ao ssh1 em uma máquina remota " +"para carregar atualizações distribuídas." + +#. (itstool) path: listitem/para +#: article.translate.xml:120 +msgid "" +"A web server, like Apache, with over half of the " +"space required for the build. For instance, test builds for 7.1 and 7.2 " +"consume a total amount of 4 GB, and the webserver space needed to distribute " +"these updates is 2.6 GB." +msgstr "" +"Um servidor web, como o Apache, com mais da " +"metade do espaço necessário para a construção. Por exemplo, as compilações " +"de teste para 7.1 e 7.2 consomem uma quantidade total de 4 GB e o espaço do " +"servidor da web necessário para distribuir essas atualizações é de 2.6 GB." + *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Wed Sep 12 05:23:00 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 89FF910A9885; Wed, 12 Sep 2018 05:23:00 +0000 (UTC) (envelope-from gordon@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3657871DCD; Wed, 12 Sep 2018 05:23:00 +0000 (UTC) (envelope-from gordon@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2EF9322339; Wed, 12 Sep 2018 05:23:00 +0000 (UTC) (envelope-from gordon@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8C5N0lt031161; Wed, 12 Sep 2018 05:23:00 GMT (envelope-from gordon@FreeBSD.org) Received: (from gordon@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8C5MwJh031147; Wed, 12 Sep 2018 05:22:58 GMT (envelope-from gordon@FreeBSD.org) Message-Id: <201809120522.w8C5MwJh031147@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gordon set sender to gordon@FreeBSD.org using -f From: Gordon Tetlow Date: Wed, 12 Sep 2018 05:22:58 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52250 - in head/share: security/advisories security/patches/EN-18:08 security/patches/SA-18:12 xml X-SVN-Group: doc-head X-SVN-Commit-Author: gordon X-SVN-Commit-Paths: in head/share: security/advisories security/patches/EN-18:08 security/patches/SA-18:12 xml X-SVN-Commit-Revision: 52250 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 05:23:00 -0000 Author: gordon (src,ports committer) Date: Wed Sep 12 05:22:58 2018 New Revision: 52250 URL: https://svnweb.freebsd.org/changeset/doc/52250 Log: Add SA-18:12, EN-18:08. Approved by: so Added: head/share/security/advisories/FreeBSD-EN-18:08.lazyfpu.asc (contents, props changed) head/share/security/advisories/FreeBSD-SA-18:12.elf.asc (contents, props changed) head/share/security/patches/EN-18:08/ head/share/security/patches/EN-18:08/lazyfpu-11.patch (contents, props changed) head/share/security/patches/EN-18:08/lazyfpu-11.patch.asc (contents, props changed) head/share/security/patches/SA-18:12/ head/share/security/patches/SA-18:12/elf.patch (contents, props changed) head/share/security/patches/SA-18:12/elf.patch.asc (contents, props changed) Modified: head/share/xml/advisories.xml head/share/xml/notices.xml Added: head/share/security/advisories/FreeBSD-EN-18:08.lazyfpu.asc ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/security/advisories/FreeBSD-EN-18:08.lazyfpu.asc Wed Sep 12 05:22:58 2018 (r52250) @@ -0,0 +1,140 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +============================================================================= +FreeBSD-EN-18:08.lazyfpu Errata Notice + The FreeBSD Project + +Topic: LazyFPU remediation causes potential data corruption + +Category: core +Module: kernel +Announced: 2018-09-12 +Credits: Gleb Kurtsou +Affects: FreeBSD 10.4-STABLE, 11.1 and later. +Corrected: 2018-07-31 10:18:30 UTC (stable/11, 11.1-STABLE) + 2018-09-12 05:08:49 UTC (releng/11.2, 11.2-RELEASE-p3) + 2018-09-12 05:08:49 UTC (releng/11.1, 11.1-RELEASE-p14) + 2018-08-03 14:12:37 UTC (stable/10, 10.4-STABLE) + +For general information regarding FreeBSD Errata Notices and Security +Advisories, including descriptions of the fields above, security +branches, and the following sections, please visit +. + +Special Note: While SA-18:07.lazyfpu has been fixed in 10.4-STABLE, it has +yet to be released for 10.4-RELEASE. As such, this EN does not apply for +that release. Once SA-18:07.lazyfpu has been updated for 10.4-RELEASE, +this EN will be incorporated at that time. + +I. Background + +The recent security advisory titled SA-18:07.lazyfpu resolved an issue in the +floating point unit (FPU) state handling. + +II. Problem Description + +As a result of fixing the issue described in SA-18:07.lazyfpu, a regression +was introduced. FPU state manipulation did not sufficiently prevent context +switches potentially allowing partially modified FPU context to be switched +out. Upon returning the thread to a running state, stale FPU context could +be reloaded. + +III. Impact + +The regression could potentially cause an inconsistent FPU state, leading to +data corruption. + +IV. Workaround + +No workaround is available. + +V. Solution + +Perform one of the following: + +1) Upgrade your system to a supported FreeBSD stable or release / security +branch (releng) dated after the correction date. + +Afterward, reboot the system. + +2) To update your system via a binary patch: + +Systems running a RELEASE version of FreeBSD on the i386 or amd64 +platforms can be updated via the freebsd-update(8) utility: + +# freebsd-update fetch +# freebsd-update install + +Afterward, reboot the system. + +3) To update your system via a source code patch: + +The following patches have been verified to apply to the applicable +FreeBSD release branches. + +a) Download the relevant patch from the location below, and verify the +detached PGP signature using your PGP utility. + +[FreeBSD 11.x] +# fetch https://security.FreeBSD.org/patches/EN-18:08/lazyfpu-11.patch +# fetch https://security.FreeBSD.org/patches/EN-18:08/lazyfpu-11.patch.asc +# gpg --verify lazyfpu-11.patch.asc + +b) Apply the patch. Execute the following commands as root: + +# cd /usr/src +# patch < /path/to/patch + +c) Recompile your kernel as described in + and reboot the +system. + +VI. Correction details + +The following list contains the correction revision numbers for each +affected branch. + +Branch/path Revision +- ------------------------------------------------------------------------- +stable/10/ r337254 +stable/11/ r336963 +releng/11.1/ r338607 +releng/11.2/ r338607 +- ------------------------------------------------------------------------- + +To see which files were modified by a particular revision, run the +following command, replacing NNNNNN with the revision number, on a +machine with Subversion installed: + +# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base + +Or visit the following URL, replacing NNNNNN with the revision number: + + + +VII. References + +The security advisory that introduced the regression is available at + + +The latest revision of this advisory is available at + +-----BEGIN PGP SIGNATURE----- + +iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAluYoL5fFIAAAAAALgAo +aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD +MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n +5cJovBAAl+BCwCwWy57TzqtYmYYaJlsKi461suiv2KjQWOAddFFPMgmEgRzLtmdu +hj4Ix5xMMH1efyWGZCk0zs9bN/2bL59P5NMFTC38Fg18fVUHC3u9SYYILvh+eTeH +s9/mkTO5nJ0LXZi3RrS4fi12Zqkiu3JuT9lcADdg8dtqRK4L0l77NZ7HD9p/mPX0 +LkLtZNTQz3Fv0LsFxwtdlljGOuJF+YYTKsC87ZHuwATDq7wTHOAmA46LVambxvxM +JQZrzUE3kDblz1sOIbMD8uW/tQ0gG4mvA3mVkuBX0yokhl7SJ4gFltjLiOEJ+n3y +7VkIcSN/5uZdjk2yWOoZuZojLLWmF0TnNrLYjIw5vacWvX25iIu+f6s9mavjZXTZ +TdtHKv+IFZfaDcaZ+mzYN87e/J7nTbe6mFwUXqG1D7ptQ3m4BP68PhtzfGrbFn/z +KXBDhaFP6MDPIMIfnP0r2HufBBlox9kcH8CKAektxVoiGAWD93+AoKVWbaR1nguQ +9k9Feo3EeS4gFQ+Jz3MQIl57nhI2FZO2SxcFowHvIqk/diXlhNhjHOy+pwSWlVH+ +8vtVlxcmFyjJBa+59QCix6PzHUn74YxRvP0NDA0zZ5WV1MwEi8J+SWaEbZMVKwJo +eJxWp1KTylk86vhaxzbRCrCzreHr6jf+Ljzn2HQPQ7rC3mRUdw0= +=+nM+ +-----END PGP SIGNATURE----- Added: head/share/security/advisories/FreeBSD-SA-18:12.elf.asc ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/security/advisories/FreeBSD-SA-18:12.elf.asc Wed Sep 12 05:22:58 2018 (r52250) @@ -0,0 +1,128 @@ +-----BEGIN PGP SIGNED MESSAGE----- +Hash: SHA512 + +============================================================================= +FreeBSD-SA-18:12.elf Security Advisory + The FreeBSD Project + +Topic: Improper ELF header parsing + +Category: core +Module: kernel +Announced: 2018-09-12 +Credits: Thomas Barabosch, Fraunhofer FKIE; Mark Johnston +Affects: All supported versions of FreeBSD. +Corrected: 2018-09-12 05:02:11 UTC (stable/11, 11.1-STABLE) + 2018-09-12 05:07:35 UTC (releng/11.2, 11.2-RELEASE-p3) + 2018-09-12 05:07:35 UTC (releng/11.1, 11.1-RELEASE-p14) + 2018-09-12 05:03:30 UTC (stable/10, 10.4-STABLE) + 2018-09-12 05:07:35 UTC (releng/10.4, 10.4-RELEASE-p12) +CVE Name: CVE-2018-6924 + +For general information regarding FreeBSD Security Advisories, +including descriptions of the fields above, security branches, and the +following sections, please visit . + +I. Background + +To execute a binary the kernel must parse the ELF header to determine the +entry point address, the program interpreter, and other parameters. + +II. Problem Description + +Insufficient validation was performed in the ELF header parser, and malformed +or otherwise invalid ELF binaries were not rejected as they should be. + +III. Impact + +Execution of a malicious ELF binary may result in a kernel crash or may +disclose kernel memory. + +IV. Workaround + +No workaround is available. + +V. Solution + +Upgrade your vulnerable system to a supported FreeBSD stable or +release / security branch (releng) dated after the correction date, and +reboot. + +1) To update your vulnerable system via a binary patch: + +Systems running a RELEASE version of FreeBSD on the i386 or amd64 +platforms can be updated via the freebsd-update(8) utility: + +# freebsd-update fetch +# freebsd-update install +# shutdown -r +30 "Rebooting for security update" + +2) To update your vulnerable system via a source code patch: + +The following patches have been verified to apply to the applicable +FreeBSD release branches. + +a) Download the relevant patch from the location below, and verify the +detached PGP signature using your PGP utility. + +# fetch https://security.FreeBSD.org/patches/SA-18:12/elf.patch +# fetch https://security.FreeBSD.org/patches/SA-18:12/elf.patch.asc +# gpg --verify elf.patch.asc + +b) Apply the patch. Execute the following commands as root: + +# cd /usr/src +# patch < /path/to/patch + +c) Recompile your kernel as described in + and reboot the +system. + +VI. Correction details + +The following list contains the correction revision numbers for each +affected branch. + +Branch/path Revision +- ------------------------------------------------------------------------- +stable/10/ r338605 +releng/10.4/ r338606 +stable/11/ r338604 +releng/11.1/ r338606 +releng/11.2/ r338606 +- ------------------------------------------------------------------------- + +To see which files were modified by a particular revision, run the +following command, replacing NNNNNN with the revision number, on a +machine with Subversion installed: + +# svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base + +Or visit the following URL, replacing NNNNNN with the revision number: + + + +VII. References + + + +The latest revision of this advisory is available at + +-----BEGIN PGP SIGNATURE----- + +iQKTBAEBCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAluYoK9fFIAAAAAALgAo +aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD +MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n +5cKA+BAApeUtPHpy5mEHC8ftJ+3NZpfI8gcfuPE0dlJi6CpXq8/ruXN5Yt5X0E0l +hlbNGqEMckfe3F81rCXLbtu0zeAnSBfAFcm9xSBa6aSRfP4GAZtKDKwilPqqT9F8 +sOrPR/mAfxWmWcfDt8ggAx6akr2Tt48t7TiBP/kA14+CzVmp/pMU/ceFDLk8JYjY +PQzVM4fHC5xeBWtA2JjMNHnhR6XMeiDOLkgeRiRW1LhB/OwWwcb0uzVixxR34mCT +vFm1eJteAitoVclgnI//GkzZZ6b7SZkqyqODWKVLWXaYgb8/Z6SaKAQm2TWuHPEh +nzIpPGhnXZc+36Nn9/HYDKVn3skD1sYAnTMgPcUYZH3KfkohvFdHlnoGqkcnMwTy +mSKkQx9ojuLfwot7tyJCbgU/6e82ed1g9EiFZXwW8x4ePClaAvrDozz0QGwlXgyY +1jBbFp/gYznhxTetVRHo5ug5SHZgD2Ye46TCoglHX0CprhkWwpKenoCEyfyjlHXH +uI+RPd46TlQfuK4bqURRpWvNWprXGqQ0ypFVW2JJgqLPBX0QS79gzqO++C8tRqQv +e16mqzBGNIre/8FOCBpV/Z61NgxqeYo2ndHxc9VTMiFXK/2v3TDK9AvYZ1/xEvwC +IRpC+qo870B5XT/ihC/KpYI4jgM2/pK/Mdez6Q4s5M6eeCBHAgw= +=J/a5 +-----END PGP SIGNATURE----- Added: head/share/security/patches/EN-18:08/lazyfpu-11.patch ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/security/patches/EN-18:08/lazyfpu-11.patch Wed Sep 12 05:22:58 2018 (r52250) @@ -0,0 +1,272 @@ +--- sys/amd64/amd64/fpu.c.orig ++++ sys/amd64/amd64/fpu.c +@@ -744,6 +744,7 @@ + int max_ext_n, i, owned; + + pcb = td->td_pcb; ++ critical_enter(); + if ((pcb->pcb_flags & PCB_USERFPUINITDONE) == 0) { + bcopy(fpu_initialstate, get_pcb_user_save_pcb(pcb), + cpu_max_ext_state_size); +@@ -750,9 +751,9 @@ + get_pcb_user_save_pcb(pcb)->sv_env.en_cw = + pcb->pcb_initial_fpucw; + fpuuserinited(td); ++ critical_exit(); + return (_MC_FPOWNED_PCB); + } +- critical_enter(); + if (td == PCPU_GET(fpcurthread) && PCB_USER_FPU(pcb)) { + fpusave(get_pcb_user_save_pcb(pcb)); + owned = _MC_FPOWNED_FPU; +@@ -759,7 +760,6 @@ + } else { + owned = _MC_FPOWNED_PCB; + } +- critical_exit(); + if (use_xsave) { + /* + * Handle partially saved state. +@@ -779,6 +779,7 @@ + *xstate_bv |= bit; + } + } ++ critical_exit(); + return (owned); + } + +@@ -787,6 +788,7 @@ + { + struct pcb *pcb; + ++ CRITICAL_ASSERT(td); + pcb = td->td_pcb; + if (PCB_USER_FPU(pcb)) + set_pcb_flags(pcb, +@@ -845,26 +847,25 @@ + + addr->sv_env.en_mxcsr &= cpu_mxcsr_mask; + pcb = td->td_pcb; ++ error = 0; + critical_enter(); + if (td == PCPU_GET(fpcurthread) && PCB_USER_FPU(pcb)) { + error = fpusetxstate(td, xfpustate, xfpustate_size); +- if (error != 0) { +- critical_exit(); +- return (error); ++ if (error == 0) { ++ bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); ++ fpurestore(get_pcb_user_save_td(td)); ++ set_pcb_flags(pcb, PCB_FPUINITDONE | ++ PCB_USERFPUINITDONE); + } +- bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); +- fpurestore(get_pcb_user_save_td(td)); +- critical_exit(); +- set_pcb_flags(pcb, PCB_FPUINITDONE | PCB_USERFPUINITDONE); + } else { +- critical_exit(); + error = fpusetxstate(td, xfpustate, xfpustate_size); +- if (error != 0) +- return (error); +- bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); +- fpuuserinited(td); ++ if (error == 0) { ++ bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); ++ fpuuserinited(td); ++ } + } +- return (0); ++ critical_exit(); ++ return (error); + } + + /* +@@ -1037,6 +1038,7 @@ + ctx->flags = FPU_KERN_CTX_DUMMY | FPU_KERN_CTX_INUSE; + return (0); + } ++ critical_enter(); + KASSERT(!PCB_USER_FPU(pcb) || pcb->pcb_save == + get_pcb_user_save_pcb(pcb), ("mangled pcb_save")); + ctx->flags = FPU_KERN_CTX_INUSE; +@@ -1047,6 +1049,7 @@ + pcb->pcb_save = fpu_kern_ctx_savefpu(ctx); + set_pcb_flags(pcb, PCB_KERNFPU); + clear_pcb_flags(pcb, PCB_FPUINITDONE); ++ critical_exit(); + return (0); + } + +@@ -1065,7 +1068,6 @@ + + clear_pcb_flags(pcb, PCB_FPUNOSAVE | PCB_FPUINITDONE); + start_emulating(); +- critical_exit(); + } else { + KASSERT((ctx->flags & FPU_KERN_CTX_INUSE) != 0, + ("leaving not inuse ctx")); +@@ -1079,7 +1081,6 @@ + critical_enter(); + if (curthread == PCPU_GET(fpcurthread)) + fpudrop(); +- critical_exit(); + pcb->pcb_save = ctx->prev; + } + +@@ -1096,6 +1097,7 @@ + clear_pcb_flags(pcb, PCB_FPUINITDONE); + KASSERT(!PCB_USER_FPU(pcb), ("unpaired fpu_kern_leave")); + } ++ critical_exit(); + return (0); + } + +--- sys/amd64/amd64/machdep.c.orig ++++ sys/amd64/amd64/machdep.c +@@ -2158,8 +2158,10 @@ + set_fpregs(struct thread *td, struct fpreg *fpregs) + { + ++ critical_enter(); + set_fpregs_xmm(fpregs, get_pcb_user_save_td(td)); + fpuuserinited(td); ++ critical_exit(); + return (0); + } + +--- sys/i386/i386/machdep.c.orig ++++ sys/i386/i386/machdep.c +@@ -3004,6 +3004,7 @@ + set_fpregs(struct thread *td, struct fpreg *fpregs) + { + ++ critical_enter(); + if (cpu_fxsr) + npx_set_fpregs_xmm((struct save87 *)fpregs, + &get_pcb_user_save_td(td)->sv_xmm); +@@ -3011,6 +3012,7 @@ + bcopy(fpregs, &get_pcb_user_save_td(td)->sv_87, + sizeof(*fpregs)); + npxuserinited(td); ++ critical_exit(); + return (0); + } + +--- sys/i386/isa/npx.c.orig ++++ sys/i386/isa/npx.c +@@ -974,14 +974,15 @@ + return (_MC_FPOWNED_NONE); + + pcb = td->td_pcb; ++ critical_enter(); + if ((pcb->pcb_flags & PCB_NPXINITDONE) == 0) { + bcopy(npx_initialstate, get_pcb_user_save_pcb(pcb), + cpu_max_ext_state_size); + SET_FPU_CW(get_pcb_user_save_pcb(pcb), pcb->pcb_initial_npxcw); + npxuserinited(td); ++ critical_exit(); + return (_MC_FPOWNED_PCB); + } +- critical_enter(); + if (td == PCPU_GET(fpcurthread)) { + fpusave(get_pcb_user_save_pcb(pcb)); + if (!cpu_fxsr) +@@ -995,7 +996,6 @@ + } else { + owned = _MC_FPOWNED_PCB; + } +- critical_exit(); + if (use_xsave) { + /* + * Handle partially saved state. +@@ -1018,6 +1018,7 @@ + *xstate_bv |= bit; + } + } ++ critical_exit(); + return (owned); + } + +@@ -1026,6 +1027,7 @@ + { + struct pcb *pcb; + ++ CRITICAL_ASSERT(td); + pcb = td->td_pcb; + if (PCB_USER_FPU(pcb)) + pcb->pcb_flags |= PCB_NPXINITDONE; +@@ -1083,28 +1085,26 @@ + if (cpu_fxsr) + addr->sv_xmm.sv_env.en_mxcsr &= cpu_mxcsr_mask; + pcb = td->td_pcb; ++ error = 0; + critical_enter(); + if (td == PCPU_GET(fpcurthread) && PCB_USER_FPU(pcb)) { + error = npxsetxstate(td, xfpustate, xfpustate_size); +- if (error != 0) { +- critical_exit(); +- return (error); ++ if (error == 0) { ++ if (!cpu_fxsr) ++ fnclex(); /* As in npxdrop(). */ ++ bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); ++ fpurstor(get_pcb_user_save_td(td)); ++ pcb->pcb_flags |= PCB_NPXUSERINITDONE | PCB_NPXINITDONE; + } +- if (!cpu_fxsr) +- fnclex(); /* As in npxdrop(). */ +- bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); +- fpurstor(get_pcb_user_save_td(td)); +- critical_exit(); +- pcb->pcb_flags |= PCB_NPXUSERINITDONE | PCB_NPXINITDONE; + } else { +- critical_exit(); + error = npxsetxstate(td, xfpustate, xfpustate_size); +- if (error != 0) +- return (error); +- bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); +- npxuserinited(td); ++ if (error == 0) { ++ bcopy(addr, get_pcb_user_save_td(td), sizeof(*addr)); ++ npxuserinited(td); ++ } + } +- return (0); ++ critical_exit(); ++ return (error); + } + + static void +@@ -1373,6 +1373,7 @@ + return (0); + } + pcb = td->td_pcb; ++ critical_enter(); + KASSERT(!PCB_USER_FPU(pcb) || pcb->pcb_save == + get_pcb_user_save_pcb(pcb), ("mangled pcb_save")); + ctx->flags = FPU_KERN_CTX_INUSE; +@@ -1383,6 +1384,7 @@ + pcb->pcb_save = fpu_kern_ctx_savefpu(ctx); + pcb->pcb_flags |= PCB_KERNNPX; + pcb->pcb_flags &= ~PCB_NPXINITDONE; ++ critical_exit(); + return (0); + } + +@@ -1401,7 +1403,6 @@ + critical_enter(); + if (curthread == PCPU_GET(fpcurthread)) + npxdrop(); +- critical_exit(); + pcb->pcb_save = ctx->prev; + if (pcb->pcb_save == get_pcb_user_save_pcb(pcb)) { + if ((pcb->pcb_flags & PCB_NPXUSERINITDONE) != 0) +@@ -1416,6 +1417,7 @@ + pcb->pcb_flags &= ~PCB_NPXINITDONE; + KASSERT(!PCB_USER_FPU(pcb), ("unpaired fpu_kern_leave")); + } ++ critical_exit(); + return (0); + } + Added: head/share/security/patches/EN-18:08/lazyfpu-11.patch.asc ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/security/patches/EN-18:08/lazyfpu-11.patch.asc Wed Sep 12 05:22:58 2018 (r52250) @@ -0,0 +1,18 @@ +-----BEGIN PGP SIGNATURE----- + +iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAluYoMlfFIAAAAAALgAo +aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD +MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n +5cJigg/+OvQriZe3uQx6A8cjJExzxVTmctmIcAfIxX992E3gKYW8PpomMsIoXnqm +HCBB7QPKg6k1agIegg38j1zGeLY7LU1pbLQbzJAXx1vtacILx03XpgdPutiHTUty +NhNl3S71Pk2nFik4pVC2Zqf3qQ3jsauhfItH9Z3Dgasp50/6353upvRAmALUQ/J4 +ffa/xXqcHjL3ZnNyH5oU56s9f287I89iqxz83Q2aw3jhOqoQoseeeRtg78ysWkgx +KLgvRa2FApxq3LBrjDKmEbV9ph5qHvXzLGP5/FZUN/X0RzLmGD+J6458BHpw1tJW +ZOu2NHNl79KLl5qsPtp44vwQwLYe33xKHRFBXbT83MmnDnN0qwxhzkKN/txZcbWB +KEaOo/6MnpHO3YOaw9TWJdmaV/ETT3MS276rzxEXpiJYB50exlgelfTDrKW8wiMX +WRGUgc1Mmfex0UWEQ48l0d67XpWmoQPUCLDwNks9P6qkMehlhFQZWiv4l9ZGRJp4 +6BkliNGaBBP2raMU9neMJhmd0/24AZ2vPlH2SuRvjLBCRoNA70GfvL5/9h21cQIh +7UEs5p5spDEle7B3EzJrovMs7eTl89bHKhOx76+WHpmiXpFbFKL3eiEpVYlJYrrU +zT2hI4B/mOAlHqqfgt9ygFJ4Zlbwh2rrQdioeCZTMEM4VpXLFz8= +=EN9Q +-----END PGP SIGNATURE----- Added: head/share/security/patches/SA-18:12/elf.patch ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/security/patches/SA-18:12/elf.patch Wed Sep 12 05:22:58 2018 (r52250) @@ -0,0 +1,35 @@ +--- sys/kern/imgact_elf.c.orig ++++ sys/kern/imgact_elf.c +@@ -839,7 +839,8 @@ + break; + case PT_INTERP: + /* Path to interpreter */ +- if (phdr[i].p_filesz > MAXPATHLEN) { ++ if (phdr[i].p_filesz < 2 || ++ phdr[i].p_filesz > MAXPATHLEN) { + uprintf("Invalid PT_INTERP\n"); + error = ENOEXEC; + goto ret; +@@ -870,6 +871,11 @@ + } else { + interp = __DECONST(char *, imgp->image_header) + + phdr[i].p_offset; ++ if (interp[interp_name_len - 1] != '\0') { ++ uprintf("Invalid PT_INTERP\n"); ++ error = ENOEXEC; ++ goto ret; ++ } + } + break; + case PT_GNU_STACK: +--- sys/kern/vfs_vnops.c.orig ++++ sys/kern/vfs_vnops.c +@@ -528,6 +528,8 @@ + struct vn_io_fault_args args; + int error, lock_flags; + ++ if (offset < 0 && vp->v_type != VCHR) ++ return (EINVAL); + auio.uio_iov = &aiov; + auio.uio_iovcnt = 1; + aiov.iov_base = base; Added: head/share/security/patches/SA-18:12/elf.patch.asc ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/share/security/patches/SA-18:12/elf.patch.asc Wed Sep 12 05:22:58 2018 (r52250) @@ -0,0 +1,18 @@ +-----BEGIN PGP SIGNATURE----- + +iQKTBAABCgB9FiEE/A6HiuWv54gCjWNV05eS9J6n5cIFAluYoM1fFIAAAAAALgAo +aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEZD +MEU4NzhBRTVBRkU3ODgwMjhENjM1NUQzOTc5MkY0OUVBN0U1QzIACgkQ05eS9J6n +5cL1Yw//VW6p5rRPB6mCxSZP+svZcvOlkz6pBBoMn+Ym2t7SFNYbNuVcD8GFr7F2 +a55U0LaQ9XoePdgwC7XFTfNv4Qeya1gmHvH6el93+MFFWLJV1zryN8mS4ny6oOwP +PGPINqsS1eOmbs52n1U0ANujj8KvyghgojsqbhhpQtsa6W40/klMmvKGmnq1So5B +YV8X9uOp6tB8ahkG0S+EbfH7X3o8MC/Q5hlQavmh/biQP44EU/QwqC47DudSpG3m +S5wZtz6QNwwrtRdbJeBf+HMjfxZaMO/Lw2wC3FjwfysXL14zrCEuZROGT5Qtjd+p +LQHNrzbK4qDT5c//Tuw7KBVAeOBj2a7Sl6SCt+6wu+WZe4QCbvuE5iC/vmXzQY/7 +2oGvxDLl9yOtu49vf/EQHpo3Als6ILnpz+o2FQ3s3PsDSpjmU8YK2ADRJ2lKuAcE ++i5UAcehcC2wlVI7w7dKJicDz5+4trTpRvfBh1bEjgvk1UY/uYvkwXapUo58CFUZ +xZyBOaSprjaSyzRCuTlgE7s36mJkNV0QkRCRHutb/qCm0CY2UKcWmG4hf/Wld99m +Qpr7wdydVdObQhDISqvBi1EPJ0ZSHwdvg2Pbvm10leal0azEEhVm/tGm8ENgLIh3 +5795BkrH+49PoCvUCATlsZOr1qWEtTYdK2DWjj+6rWZL7BYSMdY= +=KOL2 +-----END PGP SIGNATURE----- Modified: head/share/xml/advisories.xml ============================================================================== --- head/share/xml/advisories.xml Wed Sep 12 02:22:29 2018 (r52249) +++ head/share/xml/advisories.xml Wed Sep 12 05:22:58 2018 (r52250) @@ -8,6 +8,19 @@ 2018 + 9 + + + 12 + + + FreeBSD-SA-18:12.elf + + + + + + 8 Modified: head/share/xml/notices.xml ============================================================================== --- head/share/xml/notices.xml Wed Sep 12 02:22:29 2018 (r52249) +++ head/share/xml/notices.xml Wed Sep 12 05:22:58 2018 (r52250) @@ -8,6 +8,19 @@ 2018 + 9 + + + 12 + + + FreeBSD-EN-18:08.lazyfpu + + + + + + 6 From owner-svn-doc-all@freebsd.org Wed Sep 12 08:58:02 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1290B108C6A5; Wed, 12 Sep 2018 08:58:02 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC4CA796F2; Wed, 12 Sep 2018 08:58:01 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B28E0244D4; Wed, 12 Sep 2018 08:58:01 +0000 (UTC) (envelope-from ryusuke@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8C8w198038419; Wed, 12 Sep 2018 08:58:01 GMT (envelope-from ryusuke@FreeBSD.org) Received: (from ryusuke@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8C8w1QU038418; Wed, 12 Sep 2018 08:58:01 GMT (envelope-from ryusuke@FreeBSD.org) Message-Id: <201809120858.w8C8w1QU038418@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ryusuke set sender to ryusuke@FreeBSD.org using -f From: Ryusuke SUZUKI Date: Wed, 12 Sep 2018 08:58:01 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52251 - head/ja_JP.eucJP/share/xml X-SVN-Group: doc-head X-SVN-Commit-Author: ryusuke X-SVN-Commit-Paths: head/ja_JP.eucJP/share/xml X-SVN-Commit-Revision: 52251 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2018 08:58:02 -0000 Author: ryusuke Date: Wed Sep 12 08:58:01 2018 New Revision: 52251 URL: https://svnweb.freebsd.org/changeset/doc/52251 Log: - Merge the following from the English version: r52189 -> r52244 head/ja_JP.eucJP/share/xml/news.xml Modified: head/ja_JP.eucJP/share/xml/news.xml Modified: head/ja_JP.eucJP/share/xml/news.xml ============================================================================== --- head/ja_JP.eucJP/share/xml/news.xml Wed Sep 12 05:22:58 2018 (r52250) +++ head/ja_JP.eucJP/share/xml/news.xml Wed Sep 12 08:58:01 2018 (r52251) @@ -23,7 +23,7 @@ would like to work on. *** $FreeBSD$ - Original revision: r52189 + Original revision: r52244 --> @@ -32,6 +32,28 @@ 2018 + + + 9 + + + 6 + +

    ¿·¥³¥ß¥Ã¥¿½¢Ç¤: + Emmanuel Vadot + (ports)

    +     +     + + 2 + +

    ¿·¥³¥ß¥Ã¥¿½¢Ç¤: + Kevin Bowling + (ports)

    +     +     + +     8 From owner-svn-doc-all@freebsd.org Thu Sep 13 02:34:43 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5DDC210A2B21; Thu, 13 Sep 2018 02:34:43 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02A2F7BFA1; Thu, 13 Sep 2018 02:34:43 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id E2C787620; Thu, 13 Sep 2018 02:34:42 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8D2YgXG084511; Thu, 13 Sep 2018 02:34:42 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8D2YgjJ084508; Thu, 13 Sep 2018 02:34:42 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809130234.w8D2YgjJ084508@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Thu, 13 Sep 2018 02:34:42 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52252 - in head/pt_BR.ISO8859-1/articles: . vm-design X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/articles: . vm-design X-SVN-Commit-Revision: 52252 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 02:34:43 -0000 Author: ebrandi Date: Thu Sep 13 02:34:41 2018 New Revision: 52252 URL: https://svnweb.freebsd.org/changeset/doc/52252 Log: pt_BR.ISO8859-1/articles/vm-design: New pt_BR translation into .po format - content synchronized with en_US document (rev 43184) - article.xml converted to .po - .po file was translated to pt_BR - .po and .xml file has been set to UTF-8 encoding - information about volunteers who translated and/or revised the document was added to the header of the .po file. Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/vm-design/ head/pt_BR.ISO8859-1/articles/vm-design/Makefile (contents, props changed) head/pt_BR.ISO8859-1/articles/vm-design/article.xml (contents, props changed) head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/Makefile Modified: head/pt_BR.ISO8859-1/articles/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile Wed Sep 12 08:58:01 2018 (r52251) +++ head/pt_BR.ISO8859-1/articles/Makefile Thu Sep 13 02:34:41 2018 (r52252) @@ -27,6 +27,7 @@ SUBDIR+= problem-reports SUBDIR+= rc-scripting SUBDIR+= remote-install SUBDIR+= solid-state +SUBDIR+= vm-design DOC_PREFIX?= ${.CURDIR}/../.. .include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/vm-design/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/vm-design/Makefile Thu Sep 13 02:34:41 2018 (r52252) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: VM Design + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/vm-design/article.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/vm-design/article.xml Thu Sep 13 02:34:41 2018 (r52252) @@ -0,0 +1,343 @@ + + + + +
    + Elementos de design do sistema de VM do FreeBSD + + + + MatthewDillon
    + dillon@apollo.backplane.com +
    +     + + + FreeBSD is a registered trademark of the FreeBSD Foundation. + Linux is a registered trademark of Linus Torvalds. + Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. + Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the â„¢ or the ® symbol. + + + $FreeBSD$ + + $FreeBSD$ + + + O título é realmente apenas uma maneira extravagante de dizer que vou tentar descrever todo o grupo de itens de uma VM, espero que de uma forma que todos possam acompanhar. Pelo ultimo ano eu me concentrei em vários dos principais subsistemas do kernel dentro do FreeBSD, com os subsistemas VM e Swap sendo os mais interessantes e o NFS sendo uma tarefa necessária. Eu reescrevi apenas pequenas partes do código. Na área de VM, a única grande reescrita que fiz foi para o subsistema de troca. A maior parte do meu trabalho foi de limpeza e manutenção, com apenas uma moderada reescrita de código e sem grandes ajustes nos algorítimos do subsistema VM. A maior parte da base teórica do subsistema VM permanece inalterada e muito do crédito pelo esforço de modernização nos últimos anos pertence a John Dyson e David Greenman. Não sendo um historiador como Kirk, eu não tentarei marcar todos os vários recursos com nomes de pessoas, já que invariavelm ente vou errar. + + + + Este artigo foi publicado originalmente na edição de janeiro de 2000 do DaemonNews. Esta versão do artigo pode incluir atualizações feitas por Matt e outros autores para refletir as mudanças na implementação da VM do FreeBSD. + +     + + + Introdução + + Antes de avançarmos para o design atual, vamos dedicar um pouco de tempo a necessidade de manter e modernizar qualquer base de código duradoura. No mundo da programação, os algoritmos tendem a ser mais importantes do que o código, e é precisamente devido as raízes acadêmicas do BSD que uma grande atenção foi dada ao design do algoritmo desde o início. Mais atenção ao design geralmente leva a uma base de código limpa e flexível que pode ser facilmente modificada, estendida ou substituída ao longo do tempo. Embora o BSD seja considerado um sistema operacional antigo por algumas pessoas, aqueles de nós que trabalham nele tendem a vê-lo mais como uma base de código madura que possui vários componentes modificados, estendidos, ou substituído por código moderno. Ele evoluiu e o FreeBSD está no topo, não importa quantos anos tenha o código. Esta é uma distinção importante a ser feita e infelizmente perdida para muitas pess oas. O maior erro que um programador pode cometer é não aprender com a história, e esse é precisamente o erro que muitos outros sistemas operacionais modernos cometeram. Windows NT é o melhor exemplo disso, e as conseqüências foram terríveis. O Linux também cometeu esse erro até certo ponto - o suficiente para que nós, do BSD, possamos fazer pequenas piadas sobre isso de vez em quando, entretanto. O problema do Linux é simplesmente a falta de experiência e histórico para comparar idéias, um problema que está sendo resolvido de forma fácil e rápida pela comunidade Linux, da mesma forma como foi abordado na comunidade BSD - pelo desenvolvimento contínuo de código. Por outro lado, o povo do Windows NT, repetidamente comete os mesmos erros resolvidos no UNIX décadas atrás e depois gasta anos corrigindo-os. De novo e de novo. Eles têm um cas o grave de não foi projetado aqui e estamos sempre certos porque nosso departamento de marketing diz que sim. Tenho pouca tolerância para quem não pode aprender com a história. + + Grande parte da complexidade aparente do design do FreeBSD, especialmente no subsistema VM/Swap, é um resultado direto de ter que resolver sérios problemas de desempenho que ocorrem sob várias condições. Estes problemas não se devem ao mau design de algorítimo, mas sim a fatores ambientais. Em qualquer comparação direta entre plataformas, estes problemas tornam-se mais aparentes quando os recursos do sistema começam a ficar estressados. Como descrevo o subsistema VM/Swap do FreeBSD, o leitor deve sempre manter dois pontos em mente: + + + + O aspecto mais importante do design de desempenho é o que é conhecido como Otimizando o Caminho Crítico . Muitas vezes, as otimizações de desempenho inflam um pouco o código, para que o caminho crítico tenha um melhor desempenho. + + + + Um design sólido e generalizado supera um projeto altamente otimizado a longo prazo. Enquanto um design generalizado pode acabar sendo mais lento do que um projeto altamente otimizado quando eles são implementados pela primeira vez, o design generalizado tende a ser mais fácil de se adaptar as mudanças de condições e o projeto altamente otimizado acaba tendo que ser descartado. + + + + Qualquer base de código que sobreviva e seja sustentável por anos deve, portanto, ser projetada adequadamente desde o início, mesmo que isso custe algum desempenho. Vinte anos atrás, as pessoas ainda argumentavam que programar em assembly era melhor do que programar em uma linguagem de alto nível porque produzia um código que era dez vezes mais rápido. Hoje, a queda desse argumento é óbvia - assim como os paralelos com o design de algorítimo e a generalização de código. + + + + Objetos de VM + + A melhor maneira de começar a descrever o sistema de VM do FreeBSD é examiná-lo da perspectiva de um processo em nível de usuário. Cada processo do usuário vê um espaço de endereço de VM único, privado e contíguo, contendo vários tipos de objetos de memória. Esses objetos possuem várias características. O código do programa e os dados do programa são efetivamente um único arquivo mapeado na memória (o arquivo binário sendo executado), mas o código do programa é read-only enquanto os dados do programa são copy-on-write. O programa BSS é apenas memória alocada e preenchida com zeros sob demanda, chamado de demanda de preenchimento de página com zero. Arquivos arbitrários também podem ser mapeados na memória dentro do espaço de endereçamento como bem entender, que é como o mecanismo de biblioteca compartilhada funciona. Esses mapeamentos podem exigir modificações para permanecerem privados para o processo que os produz. A chamada do sistema d e fork adiciona uma dimensão totalmente nova ao problema de gerenciamento de VMs além da complexidade já fornecida. + + Uma página de dados binários do programa (que é uma página básica de copy-on-write) ilustra a complexidade. Um programa binário contém uma seção de dados pré-inicializada que é inicialmente mapeada diretamente a partir do arquivo de programa. Quando um programa é carregado no espaço de VM de um processo, esta área é inicialmente mapeada na memória e suportada pelo próprio binário do programa, permitindo que o sistema de VM liberte/reutilize a página e depois carregue-a de volta a partir do binário. No entanto, no momento em que um processo modifica esses dados, o sistema de VM deve fazer uma cópia privada da página para esse processo. A partir do momento que a cópia privada tenha sido modificada, o sistema de VM pode não mais liberá-la, porque não há mais como restaurá-la depois. + + Você notará imediatamente que o que originalmente era um mapeamento de arquivo simples se tornou muito mais complexo. Os dados podem ser modificados página a página, enquanto o mapeamento de arquivos abrange muitas páginas de uma só vez. A complexidade aumenta ainda mais quando existe um fork do processo. Quando um processo se duplica, o resultado são dois processos - cada um com seus próprios espaços de endereçamento privados, incluindo quaisquer modificações feitas pelo processo original antes de chamar um fork(). Seria bobagem o sistema de VM fizesse uma cópia completa dos dados no momento do fork() porque é bem possível que pelo menos um dos dois processos precise apenas ler essa página a partir de então, permitindo que a página original continue a ser usada. O que era uma página privada é feito um copy-on-write novamente, já que cada processo (pai e filho) espera que suas próprias modificações pós-fork permaneçam privadas para si mesmas e não afetem a outra. + + O FreeBSD gerencia tudo isso com um modelo de objetos de VM em camadas. O arquivo de programa binário original acaba sendo a camada de objeto de VM mais baixa. Uma camada copy-on-write é colocada acima dela para conter as páginas que tiveram que ser copiadas do arquivo original. Se o programa modificar uma página de dados pertencente ao arquivo original, o sistema de VM assumirá que existe uma falha e fará uma cópia da página na camada superior. Quando existe um fork do processo, as camadas adicionais de objetos de VM são ativadas. Isso pode fazer um pouco mais de sentido com um exemplo bastante básico. Um fork() é uma operação comum para qualquer sistema *BSD, então este exemplo irá considerar um programa que inicia e é feito um fork. Quando o processo é iniciado, o sistema de VM cria uma camada de objeto, vamos chamar isso de A: + + +---------------+ +| A | ++---------------+ A picture + + A representa o arquivo - as páginas podem ser paginadas dentro e fora da mídia física do arquivo, conforme necessário. Paginar a partir do disco é razoável para um programa, mas nós realmente não queremos voltar atrás e sobrescrever o executável. O sistema de VM, portanto, cria uma segunda camada, B, que será fisicamente suportada pelo espaço de troca: + + + + + + + + +---------------+ +| B | ++---------------+ +| A | ++---------------+ + + + + Na primeira escrita em uma página depois disso, uma nova página é criada em B e seu conteúdo é inicializado a partir de A. Todas as páginas em B podem ser paginadas para dentro ou para fora por um dispositivo de troca. Quando é feito o fork do programa, o sistema de VM cria duas novas camadas de objetos - C1 para o processo pai e C2 para o filho - que ficam no topo de B: + + + + + + + + +-------+-------+ +| C1 | C2 | ++-------+-------+ +| B | ++---------------+ +| A | ++---------------+ + + + + Neste caso, digamos que uma página em B seja modificada pelo processo pai original. O processo terá uma falha de copy-on-write e duplicará a página em C1, deixando a página original em B intocada. Agora, digamos que a mesma página em B seja modificada pelo processo filho. O processo assumirá uma falha de copy-on-write e duplicará a página em C2. A página original em B agora está completamente oculta, já que C1 e C2 têm uma cópia e B poderia, teoricamente, ser destruído se não representasse um arquivo real; no entanto, esse tipo de otimização não é trivial de se fazer, porque é muito refinado. O FreeBSD não faz essa otimização. Agora, suponha (como é frequentemente o caso) que o processo filho execute um exec(). Seu espaço de endereço atual é geralmente substituído por um novo espaço de endereço representando um novo arquivo. Nesse caso, a camada C2 é destruída: + + + + + + + + +-------+ +| C1 | ++-------+-------+ +| B | ++---------------+ +| A | ++---------------+ + + + + Neste caso, o número de filhos de B cai para um, e todos os acessos para B passam agora por C1. Isso significa que B e C1 podem ser unidas. Todas as páginas em B que também existem em C1 são excluídas de B durante a união. Assim, mesmo que a otimização na etapa anterior não possa ser feita, podemos recuperar as páginas mortas quando um dos processos finalizar ou executar um exec(). + + Este modelo cria vários problemas potenciais. O primeiro é que você pode acabar com uma pilha relativamente profunda de objetos de VM em camadas, que pode custar tempo de varredura e memória quando ocorrer uma falha. Camadas profundas podem ocorrer quando houver forks dos processos e, em seguida, houver um fork novamente (do processo pai ou filho). O segundo problema é que você pode acabar com páginas profundas inacessíveis e mortas no meio da pilha de objetos de VM. Em nosso último exemplo, se os processos pai e filho modificarem a mesma página, ambos receberão suas próprias cópias privadas da página e a página original em B não poderá mais ser acessada por ninguém. Essa página em B pode ser liberada. + + O FreeBSD resolve o problema de camadas profundas com uma otimização especial chamada All Shadowed Case. Este caso ocorre se C1 ou C2 tiverem falhas de COW suficientes para fazer uma copia de sombra completa de todas as páginas em B. Digamos que C1 consiga isso. C1 agora pode ignorar B completamente, então, em vez de temos C1->B->A e C2->B->A temos agora C1->A e C2->B->A. Mas veja o que também aconteceu - agora B tem apenas uma referência (C2), então podemos unir B e C2. O resultado final é que B é deletado inteiramente e temos C1->A e C2->A. É comum que B contenha um grande número de páginas e nem C1 nem C2 possam ofuscar completamente. Se nós forçarmos novamente e criarmos um conjunto de camadas D, no entanto, é muito mais provável que uma das camadas D eventualmente seja capaz de ofuscar completamente o conjunto de dados muito menor representado por C1 ou C2. A mesma otimização funcionará em qualquer ponto do gráfico e o grande resultado disso é que, mesmo em uma máquina diversos forks, pilhas de objetos da VM tendem a não ficar muito mais profundas do que 4. Isso é verdade tanto para o processo pai quanto para os filhos e verdadeiro quer seja o processo pai fazendo o fork ou os processos filhos fazendo forks em cascata. + + O problema da página morta ainda existe no caso em que C1 ou C2 não ofuscaram completamente as páginas de B. Devido as nossas outras otimizações, este caso não representa um grande problema e simplesmente permitimos que as páginas fiquem inativas. Se o sistema ficar com pouca memória, ele irá trocá-las, comendo uma pequena parte da swap, mas é isso. + + A vantagem do modelo de objetos de VM é que o fork() é extremamente rápido, já que não é necessária nenhuma cópia de dados real. A desvantagem é que você pode criar uma camada de Objetos de VM relativamente complexa que reduz um pouco o tratamento de falhas de página e gasta memória gerenciando as estruturas de Objetos de VM. As otimizações que o FreeBSD faz prova reduzir os problemas o suficiente para que as falhas possam ser ignoradas, não deixando nenhuma desvantagem real. + + + + Camadas de SWAP + + As páginas de dados privadas são inicialmente páginas copy-on-write ou zero-fill. Quando uma alteração e, portanto, uma cópia, é feita, o objeto de apoio original (geralmente um arquivo) não pode mais ser usado para salvar uma cópia da página quando o sistema da VM precisar reutilizá-lo para outras finalidades. É aí que o SWAP entra. O SWAP é alocado para criar um suporte de armazenamento para a memória que não o possui. O FreeBSD aloca a estrutura de gerenciamento de troca para um objeto de VM somente quando for realmente necessário. No entanto, historicamente, a estrutura de gerenciamento de troca teve problemas: + + + + Sob o FreeBSD 3.X, a estrutura de gerenciamento de swap pré-aloca uma matriz que engloba todo o objeto que requer suporte para armazenamento da swap - mesmo que apenas algumas páginas desse objeto sejam suportadas por swap. Isto cria um problema de fragmentação de memória do kernel quando grandes objetos são mapeados ou processos com fork de grandes runsizes (RSS). + + + + Além disso, para manter o controle do espaço de swap, uma lista de espaços vazios é mantida na memória do kernel, e isso tende a ficar severamente fragmentado também. Como a lista de espaços vazios é uma lista linear, o desempenho de alocação e liberação de swap é uma troca O(n)-per-page (Uma por página) não ideal. + + + + Requer que as alocações de memória do kernel ocorram durante o processo de troca de swap, e isto cria problemas de deadlock de pouca memória. + + + + O problema é ainda mais exacerbado por buracos criados devido ao algoritmo de intercalação. + + + + Além disso, o mapa de blocos da swap pode se fragmentar com bastante facilidade, resultando em alocações não contíguas. + + + + A memória do kernel também deve ser alocada dinamicamente para estruturas adicionais de gerenciamento da swap quando ocorre uma troca. + + + + É evidente a partir dessa lista que havia muito espaço para melhorias. Para o FreeBSD 4.X, eu reescrevi completamente o subsistema de swap: + + + + As estruturas de gerenciamento de swap são alocadas por meio de uma tabela de hash, em vez de um array linear, fornecendo um tamanho de alocação fixo e uma granularidade muito mais fina. + + + + Em vez de usar uma lista vinculada linearmente para acompanhar as reservas de espaço de troca, ele agora usa um bitmap de blocos de troca organizados em uma estrutura de árvores raiz com dicas de espaço livre nas estruturas do nó de origem. Isto efetivamente faz a alocação de swap e libera uma operação O(1). + + + + Todo o bitmap da árvore raiz também é pré-alocado para evitar ter que alocar a memória do kernel durante operações críticas de troca com memória baixa. Afinal de contas, o sistema tende a trocar quando está com pouca memória, por isso devemos evitar a alocação da memória do kernel nesses momentos para evitar possíveis deadlocks. + + + + Para reduzir a fragmentação, a árvore raiz é capaz de alocar grandes blocos contíguos de uma só vez, pulando pedaços menores e fragmentados. + + + + Eu não dei o último passo de ter um ponteiro de sugestão de alocação que percorria uma porção da swap conforme as alocações eram feitas a fim de garantir alocações contíguas ou pelo menos a referência localmente, mas assegurei que tal adição poderia ser feita. + + + + Quando libertar uma página + + Como o sistema de VM usa toda a memória disponível para o cache em disco, geralmente há poucas páginas realmente livres. O sistema de VM depende de poder escolher corretamente as páginas que não estão em uso para reutilizar em novas alocações. Selecionar as páginas ideais para liberar é possivelmente a função mais importante que qualquer sistema de VM pode executar, porque se fizer uma seleção ruim, o sistema de VM poderá ser desnecessariamente forçado a recuperar páginas do disco, prejudicando seriamente o desempenho do sistema. + + Quanta sobrecarga estamos dispostos a sofrer no caminho crítico para evitar a liberação da página errada? Cada escolha errada que fazemos nos custará centenas de milhares de ciclos da CPU e uma paralisação notável dos processos afetados, por isto estamos dispostos a suportar uma quantidade significativa de sobrecarga, a fim de ter certeza de que a página certa é escolhida. É por isto que o FreeBSD tende a superar outros sistemas quando os recursos de memória ficam estressados. + + O algoritmo de determinação de página livre é construído sobre um histórico do uso das páginas de memória. Para adquirir este histórico, o sistema tira proveito de um recurso de um bit usado pela página que a maioria das tabelas de página de hardware possui. + + Em qualquer caso, o bit usado na página é desmarcado e, em algum momento posterior, o sistema de VM encontra a página novamente e vê que o bit usado na página foi definido. Isso indica que a página ainda está sendo usada ativamente. Se o bit ainda estiver desmarcado, é uma indicação de que a página não está sendo usada ativamente. Ao testar este bit periodicamente, é desenvolvido um histórico de uso (na forma de um contador) para a página física. Quando, posteriormente, o sistema de VM precisar liberar algumas páginas, a verificação desse histórico se tornará a base da determinação da melhor página candidata a ser reutilizada. + + + E se o hardware não tiver o bit usado na página? + + Para as plataformas que não possuem esse recurso, o sistema realmente emula um bit usado na página. Ele remove o mapeamento ou protege uma página, forçando uma falha de página se a página for acessada novamente. Quando a falha de página acontece, o sistema simplesmente marca a página como tendo sido usada e desprotege a página para que ela possa ser usada. Embora a tomada de tais falhas de página apenas para determinar se uma página está sendo usada pareça ser uma proposta cara, é muito menos dispendioso do que reutilizar a página para outra finalidade, apenas para descobrir que um processo precisa dela e depois ir para o disco . + + + O FreeBSD faz uso de várias filas de páginas para refinar ainda mais a seleção de páginas para reutilização, bem como para determinar quando páginas inativas devem ser liberadas para o suporte ao armazenamento. Como as tabelas de páginas são entidades dinâmicas sob o FreeBSD, não custa virtualmente nada desmapear uma página do espaço de endereço de qualquer processo que a utilize. Quando uma página cadidata ser escolhida com base no contador de uso de página, isso é precisamente o que é feito. O sistema deve fazer uma distinção entre páginas limpas que teoricamente podem ser liberadas a qualquer momento, e páginas inativas que devem primeiro ser escritas em seu repositório de armazenamento antes de serem reutilizáveis. Quando uma página candidata for encontrada, ela será movida para a fila inativa, se estiver inativas, ou para a fila de cache, se estiver limpa. Um algoritmo separado baseado na proporção de páginas inativas para limpas determin a quando páginas inativas na fila inativa devem ser liberadas para o disco. Depois que isso for feito, as páginas liberadas serão movidas da fila inativa para a fila de cache. Neste ponto, as páginas na fila de cache ainda podem ser reativadas por uma falha de VM a um custo relativamente baixo. No entanto, as páginas na fila de cache são consideradas imediatamente livres e serão reutilizadas em uma forma LRU (usada menos recentemente) quando o sistema precisar alocar nova memória. + + É importante notar que o sistema de VM do FreeBSD tenta separar páginas limpas e inativas pelo motivo expresso de evitar descargas desnecessárias de páginas inativas (que consomem largura de banda de I/O), nem move páginas entre as várias filas de páginas gratuitamente quando o subsistema de memória não está sendo enfatizado. É por isto que você verá alguns sistemas com contagens de fila de cache muito baixas e contagens alta de fila ativa ao executar um comando systat -vm. À medida que o sistema de VM se torna mais estressado, ele faz um esforço maior para manter as várias filas de páginas nos níveis determinados para serem mais eficazes. + + Uma lenda urbana circulou durante anos que o Linux fez um trabalho melhor evitando trocas do que o FreeBSD, mas isso de fato não é verdade. O que estava realmente ocorrendo era que o FreeBSD estava proativamente numerando páginas não usadas a fim de abrir espaço para mais cache de disco enquanto o Linux mantinha páginas não utilizadas no núcleo e deixando menos memória disponível para páginas de cache e processo. Eu não sei se isso ainda é verdade hoje. + + + + Otimizações de Pré-Falhas ou para Zerar + + Pegar uma falha de VM não é caro se a página subjacente já estiver no núcleo e puder simplesmente ser mapeada no processo, mas pode se tornar cara se você pegar muitas delas regularmente. Um bom exemplo disso é executar um programa como ls1 ou ps1 várias vezes. Se o programa binário é mapeado na memória, mas não mapeado na tabela de páginas, então todas as páginas que serão acessadas pelo programa irão estar com falha toda vez que o programa for executado. Isso é desnecessário quando as páginas em questão já estão no cache de VM, então o FreeBSD tentará preencher previamente as tabelas de páginas de um processo com as páginas que já estão no cache de VM. Uma coisa que o FreeBSD ainda não faz é pré-copiar-durante-escrita certas páginas no exec. Por exemplo, se você executar o p rograma ls1 ao executar o vmstat 1, notará que sempre pega um determinado número de falhas de página, mesmo quando você o executa várias vezes. Estas são falhas de preenchimento com zero, não falhas de código de programa (que já foram pré-falhas). A pré-cópia de páginas em exec ou fork é uma área que poderia se utilizar de mais estudos. + + Uma grande porcentagem de falhas de página que ocorrem são falhas de preenchimento com zero. Geralmente, você pode ver isso observando a saída de vmstat -s. Estas falhas ocorrem quando um processo acessa páginas em sua área BSS. Espera-se que a área BSS seja inicialmente zero, mas o sistema de VM não se preocupa em alocar memória alguma até que o processo realmente a acesse. Quando ocorre uma falha, o sistema de VM deve alocar não apenas uma nova página, mas deve zerá-la também. Para otimizar a operação de zeramento, o sistema de VM tem a capacidade de pré-zerar páginas e marcá-las como tal, e solicitar páginas pré-zeradas quando ocorrem falhas de preenchimento com zero. O pré-zeramento ocorre sempre que a CPU está inativa, mas o número de páginas que o sistema pre-zeros é limitado, a fim de evitar que os caches de memória sejam dissipados. Este é um excelente exemplo de adição de complexidade ao sistema de VM para otimizar o caminho crítico. + + + + Otimizações da Tabela de Páginas + + As otimizações da tabela de páginas constituem a parte mais contenciosa do design de VM do FreeBSD e mostraram alguma tensão com o advento do uso sério de mmap(). Eu acho que isso é realmente uma característica da maioria dos BSDs, embora eu não tenha certeza de quando foi introduzido pela primeira vez. Existem duas otimizações principais. A primeira é que as tabelas de páginas de hardware não contêm estado persistente, mas podem ser descartadas a qualquer momento com apenas uma pequena quantidade de sobrecarga de gerenciamento. A segunda é que cada entrada ativa da tabela de páginas no sistema tem uma estrutura governante pv_entry que é amarrada na estrutura vm_page. O FreeBSD pode simplesmente iterar através desses mapeamentos que são conhecidos, enquanto o Linux deve verificar todas as tabelas de páginas que possam conter um mapeamento específico para ver se ele o faz, o que pode alcançar O(n^2) situações. É por isso que o FreeBSD tende a fazer melhores escolhas em quais páginas reutilizar ou trocar quando a memória é estressada, dando-lhe melhor desempenho em sobrecarga. No entanto, o FreeBSD requer o ajuste do kernel para acomodar situações de grandes espaços de endereços compartilhados, como aquelas que podem ocorrer em um sistema de notícias, porque ele pode rodar sem estruturas pv_entry. + + Tanto o Linux quanto o FreeBSD precisam funcionar nesta área. O FreeBSD está tentando maximizar a vantagem de um modelo de mapeamento ativo potencialmente esparso (nem todos os processos precisam mapear todas as páginas de uma biblioteca compartilhada, por exemplo), enquanto o Linux está tentando simplificar seus algoritmos. O FreeBSD geralmente tem a vantagem de desempenho aqui, ao custo de desperdiçar um pouco de memória extra, mas o FreeBSD quebra no caso em que um arquivo grande é massivamente compartilhado em centenas de processos. O Linux, por outro lado, se quebra no caso em que muitos processos mapeiam esparsamente a mesma biblioteca compartilhada e também são executados de maneira não ideal ao tentar determinar se uma página pode ser reutilizada ou não. + + + + Page Coloring + + Terminaremos com as otimizações de page coloring. Page coloring é uma otimização de desempenho projetada para garantir que acessos a páginas contíguas na memória virtual façam o melhor uso do cache do processador. Nos tempos antigos (isto é, há mais de 10 anos), os caches de processador tendiam a mapear a memória virtual em vez da memória física. Isso levou a um grande número de problemas, incluindo a necessidade de limpar o cache em cada troca de contexto em alguns casos e problemas com o alias de dados no cache. Caches de processador modernos mapeiam a memória física com precisão para resolver esses problemas. Isto significa que duas páginas lado a lado em um espaço de endereço de processos podem não corresponder a duas páginas lado a lado no cache. Na verdade, se você não for cuidadoso, as páginas lado a lado na memória virtual podem acabar usando a mesma página no cache do processador - conduzindo para que dados em cache sejam descartados pr ematuramente e reduzindo o desempenho da CPU. Isto é verdade mesmo com caches auto associativos de múltiplas vias (embora o efeito seja um pouco mitigado). + + O código de alocação de memória do FreeBSD implementa otimizações de page coloring, o que significa que o código de alocação de memória tentará localizar páginas livres contíguas do ponto de vista do cache. Por exemplo, se a página 16 da memória física for atribuída à página 0 da memória virtual de um processo e o cache puder conter 4 páginas, o código de page coloring não atribuirá a página 20 da memória física a página 1 da memória virtual de um processo. Em vez disso, atribui a página 21 da memória física. O código de page coloring tenta evitar assimilar a página 20, porque ela é mapeada sobre a mesma memória cache da página 16 e resultaria em um armazenamento não otimizado. Este código adiciona uma quantidade significativa de complexidade ao subsistema de alocação de memória de VM, como você pode imaginar, mas o resultado vale o esforço. Page coloring torna a memória de VM tão determinante quanto a memória física em relaà §Ã£o ao desempenho do cache. + + + + Conclusão + + A memória virtual em sistemas operacionais modernos deve abordar vários problemas diferentes de maneira eficiente e para muitos padrões de uso diferentes. A abordagem modular e algorítmica que o BSD historicamente teve nos permite estudar e entender a implementação atual, bem como substituir de forma relativamente limpa grandes seções do código. Houve uma série de melhorias no sistema de VM do FreeBSD nos últimos anos e o trabalho está em andamento. + + + + Sessão bônus de QA por Allen Briggs <email>briggs@ninthwonder.com</email> + + + + + O que é o algoritmo de intercalação ao qual você se refere em sua listagem dos males dos arranjos de swap do FreeBSD 3.X? + + + + O FreeBSD usa um intercalador de swap fixo, cujo padrão é 4. Isso significa que o FreeBSD reserva espaço para quatro áreas de swap, mesmo se você tiver apenas uma, duas ou três. Como a swap é intercalada, o espaço de endereçamento linear representando as quatro áreas de troca estará fragmentado se você não tiver quatro áreas de troca. Por exemplo, se você tiver duas áreas de swap, A e B, a representação do espaço de endereçamento do FreeBSD para esta área de troca será intercalada em blocos de 16 páginas: + + A B C D A B C D A B C D A B C D + + O FreeBSD 3.X usa uma abordagem de lista sequencial de regiões livres para contabilizar as áreas de swap livres. A ideia é que grandes blocos de espaço linear livre possam ser representados com um único nó da lista (kern/subr_rlist.c). Mas devido a fragmentação, a lista sequencial acaba sendo insanamente fragmentada. No exemplo acima, a swap completamente sem uso terá A e B mostrados como livres e C e D mostrados como todos alocados. Cada sequência A-B requer um nó da lista para considerar porque C e D são buracos, portanto, o nó de lista não pode ser combinado com a próxima sequência A-B. + + Por que nós intercalamos nosso espaço de swap em vez de apenas colocar as áreas de swap no final e fazer algo mais sofisticado? Porque é muito mais fácil alocar trechos lineares de um espaço de endereçamento e ter o resultado automaticamente intercalado em vários discos do que tentar colocar esta sofisticação em outro lugar. + + A fragmentação causa outros problemas. Sendo uma lista linear sob 3.X, e tendo uma enorme quantidade de fragmentação inerente, alocando e liberando swap leva a ser um algoritmo O(N) ao invés de um algoritmo O(1). Combinado com outros fatores (troca pesada) e você começa a entrar em níveis de sobrecarga O(N^2) e O(N^3), o que é ruim. O sistema 3.X também pode precisar alocar o KVM durante uma operação de troca para criar um novo nó da lista que pode levar a um impasse se o sistema estiver tentando fazer uma liberação de página em uma situação de pouca memória. + + No 4.X, não usamos uma lista sequencial. Em vez disto, usamos uma árvore raiz e bitmaps de blocos de swap em vez de lista de nós variáveis. Aceitamos o sucesso de pré-alocar todos os bitmaps necessários para toda a área de swap na frente, mas acaba desperdiçando menos memória devido ao uso de um bitmap (um bit por bloco) em vez de uma lista encadeada de nós. O uso de uma árvore raiz em vez de uma lista sequencial nos dá quase o desempenho O(1), não importa o quão fragmentada a árvore se torne. + + + + + + Como a separação de páginas limpas e sujas (inativas) está relacionada à situação em que você vê baixas contagens de filas de cache e altas contagens de filas ativas no systat -vm? As estatísticas do systat rolam as páginas ativa e inativas juntas para a contagem de filas ativas? + + Eu não entendo o seguinte: + +
    + É importante notar que o sistema de VM do FreeBSD tenta separar páginas limpas e inativas pelo motivo expresso de evitar descargas desnecessárias de páginas inativas (que consomem largura de banda de I/O), nem mover páginas entre as várias filas de páginas gratuitamente quando subsistema de memória não está sendo estressado. É por itso que você verá alguns sistemas com contagens de fila de cache muito baixas e contagens de fila ativa altas ao executar um comando systat -vm. +
    +     + + + Sim, isto é confuso. A relação é meta versus realidade. Nosso objetivo é separar as páginas, mas a realidade é que, se não estamos em uma crise de memória, não precisamos realmente fazer isso. + + O que isto significa é que o FreeBSD não tentará muito separar páginas sujas (fila inativa) de páginas limpas (fila de cache) quando o sistema não está sendo estressado, nem vai tentar desativar páginas (fila ativa -> fila inativa) quando o sistema não está sendo estressado, mesmo que não estejam sendo usados. + +     + + + + No exemplo ls1 / vmstat 1, algumas falhas de página não seriam falhas de página de dados (COW do arquivo executável para a página privada)? Ou seja, eu esperaria que as falhas de página fossem um preenchimento com zero e alguns dados do programa. Ou você está sugerindo que o FreeBSD faz pré-COW para os dados do programa? + + + + Uma falha de COW pode ser preenchimento com zero ou dados de programa. O mecanismo é o mesmo dos dois modos, porque os dados do programa de apoio quase certamente já estão no cache. Eu estou realmente juntando os dois. O FreeBSD não faz o pré-COW dos dados do programa ou preenchimento com zero, mas faz pré-mapeamento de páginas que existem em seu cache. + + + + + + Em sua seção sobre otimizações de tabela de páginas, você pode dar um pouco mais de detalhes sobre pv_entry e vm_page (ou vm_page deveria ser vm_pmap- como em 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? Especificamente, que tipo de operação/reação exigiria a varredura dos mapeamentos? + + Como o Linux faz no caso onde o FreeBSD quebra (compartilhando um grande mapeamento de arquivos em muitos processos)? + + + + Uma vm_page representa uma tupla (objeto,índice#). Um pv_entry representa uma entrada de tabela de página de hardware (pte). Se você tem cinco processos compartilhando a mesma página física, e três dessas tabelas de páginas atualmente mapeiam a página, esta página será representada por uma única estrutura vm_page e três estruturas pv_entry. + + As estruturas pv_entry representam apenas as páginas mapeadas pela MMU (uma pv_entry representa uma pte). Isso significa que quando precisamos remover todas as referências de hardware para uma vm_page (para reutilizar a página para outra coisa, paginar, limpar, inativar e assim por diante), podemos simplesmente escanear a lista encadeada de pv_entry associada a essa vm_page para remover ou modificar os pte's de suas tabelas de páginas. + + No Linux, não existe essa lista vinculada. Para remover todos os mapeamentos de tabelas de páginas de hardware para um vm_page, o linux deve indexar em todos os objetos de VM que possam ter mapeado a página. Por exemplo, se você tiver 50 processos, todos mapeando a mesma biblioteca compartilhada e quiser se livrar da página X nessa biblioteca, será necessário indexar na tabela de páginas para cada um desses 50 processos, mesmo se apenas 10 deles realmente tiverem mapeado a página. Então, o Linux está trocando a simplicidade de seu design com o desempenho. Muitos algoritmos de VM que são O(1) ou (pequeno N) no FreeBSD acabam sendo O(N), O(N^2), ou pior no Linux. Como os pte's que representam uma determinada página em um objeto tendem a estar no mesmo offset em todas as tabelas de páginas em que estão mapeados, reduzir o número de acessos nas tabelas de páginas no mesmo pte offset evitará a linha de cache L1 para esse deslocamento, o que pode levar a um melhor desempenho. + + O FreeBSD adicionou complexidade (o esquema pv_entry) para aumentar o desempenho (para limitar os acessos da tabela de páginas a somente aqueles pte's que precisam ser modificados). + + Mas o FreeBSD tem um problema de escalonamento que o Linux não possui, pois há um número limitado de estruturas pv_entry e isso causa problemas quando você tem um compartilhamento massivo de dados. Nesse caso, você pode ficar sem estruturas pv_entry, mesmo que haja bastante memória livre disponível. Isto pode ser corrigido com bastante facilidade aumentando o número de estruturas pv_entry na configuração do kernel, mas realmente precisamos encontrar uma maneira melhor de fazê-lo. + + Em relação à sobrecarga de memória de uma tabela de páginas verso do esquema pv_entry: o Linux usa tabelas permanentes que não são descartadas, mas não precisa de um pv_entry para cada pte potencialmente mapeado. O FreeBSD usa tabelas de páginas throw away, mas adiciona em uma estrutura pv_entry para cada pte realmente mapeado. Eu acho que a utilização da memória acaba sendo a mesma, dando ao FreeBSD uma vantagem algorítmica com sua capacidade de jogar fora tabelas de páginas a vontade com uma sobrecarga muito baixa. + + + + + + Finalmente, na seção de page coloring, pode ser útil descrever um pouco mais o que você quer dizer aqui. Eu não segui bem isso. + + + + Você sabe como funciona um cache de memória de hardware L1? Vou explicar: Considere uma máquina com 16MB de memória principal, mas apenas 128K de cache L1. Geralmente, a maneira como este cache funciona é que cada bloco de 128K de memória principal usa o mesmo 128K de cache. Se você acessar o offset 0 na memória principal e depois deslocar 128K na memória principal, você pode acabar jogando fora os dados em cache que você leu do offset 0! + + Agora estou simplificando muito as coisas. O que acabei de descrever é o que é chamado de cache de memória de hardware diretamente mapeado. A maioria dos caches modernos são chamados de definição de associações de 2 vias ou definição de associações de 4 vias. A definição de associacões permite acessar até N regiões de memória diferentes que se sobrepõem à mesma memória de cache sem destruir os dados armazenados em cache anteriormente. Mas apenas N. + + Então, se eu tenho um cache associativo de 4-way, eu posso acessar o offset 0, offset 128K, 256K e offset 384K e ainda ser capaz de acessar o offset 0 novamente e tê-lo vindo do cache L1. Se eu, então, acessar o deslocamento 512K, no entanto, um dos quatro objetos de dados armazenados anteriormente em cache será descartado pelo cache. + + É extremamente importante… extremamente importante para que a maioria dos acessos de memória de um processador possam vir do cache L1, porque o cache L1 opera na frequência do processador. No momento em que você tem uma falha de cache L1 e precisa ir para o cache L2 ou para a memória principal, o processador irá parar e potencialmente sentar-se por centenas de instruções aguardando uma leitura de memória principal para completar. A memória principal (o ram dinâmico que você coloca em um computador) é lenta, quando comparada à velocidade de um núcleo de processador moderno. + + Ok, agora em page coloring: Todos os caches de memória modernos são conhecidos como caches físicos. Eles armazenam em cache endereços de memória física, não endereços de memória virtual. Isto permite que o cache seja deixado sozinho em uma opção de contexto de processo, o que é muito importante. + + Mas no mundo UNIX você está lidando com espaços de endereço virtual, não com espaços de endereço físico. Qualquer programa que você escreva verá o espaço de endereço virtual dado a ele. As páginas reais físicas subjacentes a este espaço de endereço virtual não são necessariamente contíguas fisicamente! De fato, você pode ter duas páginas que estão lado a lado em um espaço de endereço de processos que termina no offset 0 e desloca 128K na memória física. + + Um programa normalmente pressupõe que duas páginas lado a lado serão armazenadas em cache de maneira ideal. Ou seja, você pode acessar objetos de dados em ambas as páginas sem que elas descartem a entrada de cache uma da outra. Mas isso só é verdadeiro se as páginas físicas subjacentes ao espaço de endereço virtual forem contíguas (no que se refere ao cache). + + É isso que o disfarce de página faz. Em vez de atribuir páginas físicas aleatórias a endereços virtuais, o que pode resultar em desempenho de cache não ideal, o disfarce de página atribui páginas físicas razoavelmente contíguas a endereços virtuais. Assim, os programas podem ser escritos sob a suposição de que as características do cache de hardware subjacente são as mesmas para seu espaço de endereço virtual, como seriam se o programa tivesse sido executado diretamente em um espaço de endereço físico. + + Note que eu digo razoavelmente contíguo ao invés de simplesmente contíguo. Do ponto de vista de um cache mapeado direto de 128K, o endereço físico 0 é o mesmo que o endereço físico 128K. Assim, duas páginas lado a lado em seu espaço de endereço virtual podem acabar sendo compensadas em 128K e compensadas em 132K na memória física, mas também podem ser facilmente compensadas em 128K e compensadas em 4K na memória física e ainda manter as mesmas características de desempenho de cache. Portanto, disfarce de página não tem que atribuir páginas verdadeiramente contíguas de memória física a páginas contíguas de memória virtual, basta certificar-se de atribuir páginas contíguas do ponto de vista do desempenho e da operação do cache. + + +     +     +
    Added: head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/vm-design/pt_BR.po Thu Sep 13 02:34:41 2018 (r52252) @@ -0,0 +1,1846 @@ +# $FreeBSD$ +# André Franciosi , 2018. #zanata +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Silvio Ap Silva , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-13 02:27+0000\n" +"PO-Revision-Date: 2018-09-12 11:08+0000\n" +"Last-Translator: André Franciosi \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018\n" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Silvio Ap Silva, contato@kanazuchi.com, 2018\n" +"André Franciosi, andre@franciosi.org, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:6 +msgid "Design elements of the FreeBSD VM system" +msgstr "Elementos de design do sistema de VM do FreeBSD" + +#. (itstool) path: affiliation/address +#: article.translate.xml:11 +#, no-wrap +msgid "" +"\n" +"\t dillon@apollo.backplane.com\n" +"\t " +msgstr "" +"\n" +"\t dillon@apollo.backplane.com\n" +"\t " + +#. (itstool) path: authorgroup/author +#: article.translate.xml:10 +msgid "" +"MatthewDillon <_:address-1/> " +msgstr "" +"MatthewDillon <_:address-1/> " + +#. (itstool) path: legalnotice/para +#: article.translate.xml:18 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:20 +msgid "Linux is a registered trademark of Linus Torvalds." +msgstr "Linux is a registered trademark of Linus Torvalds." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:22 +msgid "" +"Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows " +"NT are either registered trademarks or trademarks of Microsoft Corporation " +"in the United States and/or other countries." +msgstr "" +"Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows " +"NT are either registered trademarks or trademarks of Microsoft Corporation " +"in the United States and/or other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:26 +msgid "" +"Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The " +"Open Group are trademarks of The Open Group in the United States and other " +"countries." +msgstr "" +"Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The " +"Open Group are trademarks of The Open Group in the United States and other " +"countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:30 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:38 article.translate.xml:40 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/vm-design/article.xml 43184 " +"2013-11-13 07:52:45Z hrs $" +msgstr "" +"$FreeBSD: head/en_US.ISO8859-1/articles/vm-design/article.xml 43184 " +"2013-11-13 07:52:45Z hrs $" + +#. (itstool) path: abstract/para +#: article.translate.xml:43 +msgid "" +"The title is really just a fancy way of saying that I am going to attempt to " +"describe the whole VM enchilada, hopefully in a way that everyone can " +"follow. For the last year I have concentrated on a number of major kernel " +"subsystems within FreeBSD, with the VM and Swap subsystems being the most " +"interesting and NFS being a necessary chore. I rewrote only " +"small portions of the code. In the VM arena the only major rewrite I have " +"done is to the swap subsystem. Most of my work was cleanup and maintenance, " +"with only moderate code rewriting and no major algorithmic adjustments " +"within the VM subsystem. The bulk of the VM subsystem's theoretical base " +"remains unchanged and a lot of the credit for the modernization effort in " +"the last few years belongs to John Dyson and David Greenman. Not being a " +"historian like Kirk I will not attempt to tag all the various features with " +"peoples names, since I will invariably get it wrong." +msgstr "" +"O título é realmente apenas uma maneira extravagante de dizer que vou tentar " +"descrever todo o grupo de itens de uma VM, espero que de uma forma que todos " +"possam acompanhar. Pelo ultimo ano eu me concentrei em vários dos principais " +"subsistemas do kernel dentro do FreeBSD, com os subsistemas VM e Swap sendo " +"os mais interessantes e o NFS sendo uma tarefa necessária. Eu " +"reescrevi apenas pequenas partes do código. Na área de VM, a única grande " +"reescrita que fiz foi para o subsistema de troca. A maior parte do meu " +"trabalho foi de limpeza e manutenção, com apenas uma moderada reescrita de " +"código e sem grandes ajustes nos algorítimos do subsistema VM. A maior parte " +"da base teórica do subsistema VM permanece inalterada e muito do crédito " +"pelo esforço de modernização nos últimos anos pertence a John Dyson e David " +"Greenman. Não sendo um historiador como Kirk, eu não tentarei marcar todos " +"os vários recursos com nomes de pessoas, já que invariavelmente vou errar." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:60 +msgid "" +"This article was originally published in the January 2000 issue of DaemonNews. This version of " +"the article may include updates from Matt and other authors to reflect " +"changes in FreeBSD's VM implementation." +msgstr "" +"Este artigo foi publicado originalmente na edição de janeiro de 2000 do " +"DaemonNews. Esta " +"versão do artigo pode incluir atualizações feitas por Matt e outros autores " +"para refletir as mudanças na implementação da VM do FreeBSD." + +#. (itstool) path: sect1/title +#: article.translate.xml:68 +msgid "Introduction" +msgstr "Introdução" + +#. (itstool) path: sect1/para +#: article.translate.xml:70 +msgid "" +"Before moving along to the actual design let's spend a little time on the " +"necessity of maintaining and modernizing any long-living codebase. In the " +"programming world, algorithms tend to be more important than code and it is " +"precisely due to BSD's academic roots that a great deal of attention was " +"paid to algorithm design from the beginning. More attention paid to the " +"design generally leads to a clean and flexible codebase that can be fairly " +"easily modified, extended, or replaced over time. While BSD is considered an " +"old operating system by some people, those of us who work on " +"it tend to view it more as a mature codebase which has " +"various components modified, extended, or replaced with modern code. It has " +"evolved, and FreeBSD is at the bleeding edge no matter how old some of the " +"code might be. This is an important distinction to make and one that is " +"unfortunately lost to many people. The biggest error a programmer can make " +"is to not learn from history, and this is precisely the error that many " +"other modern operating systems have made. Windows NT is the best example of this, and the consequences " +"have been dire. Linux also makes this mistake to some degree—enough that we " +"BSD folk can make small jokes about it every once in a while, anyway. " +"Linux's problem is simply one of a lack of experience and history to compare " +"ideas against, a problem that is easily and rapidly being addressed by the " +"Linux community in the same way it has been addressed in the BSD community—" +"by continuous code development. The Windows NT folk, on the other hand, repeatedly make the same " +"mistakes solved by UNIX decades " +"ago and then spend years fixing them. Over and over again. They have a " +"severe case of not designed here and we are always " +"right because our marketing department says so. I have little " +"tolerance for anyone who cannot learn from history." +msgstr "" +"Antes de avançarmos para o design atual, vamos dedicar um pouco de tempo a " +"necessidade de manter e modernizar qualquer base de código duradoura. No " +"mundo da programação, os algoritmos tendem a ser mais importantes do que o " +"código, e é precisamente devido as raízes acadêmicas do BSD que uma grande " +"atenção foi dada ao design do algoritmo desde o início. Mais atenção ao " +"design geralmente leva a uma base de código limpa e flexível que pode ser " +"facilmente modificada, estendida ou substituída ao longo do tempo. Embora o " +"BSD seja considerado um sistema operacional antigo por " +"algumas pessoas, aqueles de nós que trabalham nele tendem a vê-lo mais como " +"uma base de código madura que possui vários componentes " +"modificados, estendidos, ou substituído por código moderno. Ele evoluiu e o " +"FreeBSD está no topo, não importa quantos anos tenha o código. Esta é uma " +"distinção importante a ser feita e infelizmente perdida para muitas pessoas. " +"O maior erro que um programador pode cometer é não aprender com a história, " +"e esse é precisamente o erro que muitos outros sistemas operacionais " +"modernos cometeram. Windows NT é " +"o melhor exemplo disso, e as conseqüências foram terríveis. O Linux também " +"cometeu esse erro até certo ponto - o suficiente para que nós, do BSD, " +"possamos fazer pequenas piadas sobre isso de vez em quando, entretanto. O " +"problema do Linux é simplesmente a falta de experiência e histórico para " +"comparar idéias, um problema que está sendo resolvido de forma fácil e " +"rápida pela comunidade Linux, da mesma forma como foi abordado na comunidade " +"BSD - pelo desenvolvimento contínuo de código. Por outro lado, o povo do " +"Windows NT, repetidamente comete " +"os mesmos erros resolvidos no UNIX décadas atrás e depois gasta anos corrigindo-os. De novo e de " +"novo. Eles têm um caso grave de não foi projetado aqui e " +"estamos sempre certos porque nosso departamento de marketing diz que " +"sim. Tenho pouca tolerância para quem não pode aprender com a " +"história." + +#. (itstool) path: sect1/para +#: article.translate.xml:99 +msgid "" +"Much of the apparent complexity of the FreeBSD design, especially in the VM/" +"Swap subsystem, is a direct result of having to solve serious performance " +"issues that occur under various conditions. These issues are not due to bad " +"algorithmic design but instead rise from environmental factors. In any " +"direct comparison between platforms, these issues become most apparent when " +"system resources begin to get stressed. As I describe FreeBSD's VM/Swap " +"subsystem the reader should always keep two points in mind:" +msgstr "" +"Grande parte da complexidade aparente do design do FreeBSD, especialmente no " +"subsistema VM/Swap, é um resultado direto de ter que resolver sérios " +"problemas de desempenho que ocorrem sob várias condições. Estes problemas " +"não se devem ao mau design de algorítimo, mas sim a fatores ambientais. Em " +"qualquer comparação direta entre plataformas, estes problemas tornam-se mais " +"aparentes quando os recursos do sistema começam a ficar estressados. Como " +"descrevo o subsistema VM/Swap do FreeBSD, o leitor deve sempre manter dois " +"pontos em mente:" + +#. (itstool) path: listitem/para +#: article.translate.xml:110 +msgid "" +"The most important aspect of performance design is what is known as " +"Optimizing the Critical Path. It is often the case that " +"performance optimizations add a little bloat to the code in order to make " +"the critical path perform better." +msgstr "" +"O aspecto mais importante do design de desempenho é o que é conhecido como " +"Otimizando o Caminho Crítico . Muitas vezes, as otimizações " +"de desempenho inflam um pouco o código, para que o caminho crítico tenha um " +"melhor desempenho." + +#. (itstool) path: listitem/para +#: article.translate.xml:117 +msgid "" +"A solid, generalized design outperforms a heavily-optimized design over the " +"long run. While a generalized design may end up being slower than an heavily-" +"optimized design when they are first implemented, the generalized design " +"tends to be easier to adapt to changing conditions and the heavily-optimized " +"design winds up having to be thrown away." +msgstr "" +"Um design sólido e generalizado supera um projeto altamente otimizado a " +"longo prazo. Enquanto um design generalizado pode acabar sendo mais lento do " +"que um projeto altamente otimizado quando eles são implementados pela " +"primeira vez, o design generalizado tende a ser mais fácil de se adaptar as " +"mudanças de condições e o projeto altamente otimizado acaba tendo que ser " +"descartado." + +#. (itstool) path: sect1/para +#: article.translate.xml:126 +msgid "" +"Any codebase that will survive and be maintainable for years must therefore " +"be designed properly from the beginning even if it costs some performance. " +"Twenty years ago people were still arguing that programming in assembly was " +"better than programming in a high-level language because it produced code " +"that was ten times as fast. Today, the fallibility of that argument is " +"obvious  — as are the parallels to algorithmic design and code " +"generalization." +msgstr "" +"Qualquer base de código que sobreviva e seja sustentável por anos deve, " +"portanto, ser projetada adequadamente desde o início, mesmo que isso custe " +"algum desempenho. Vinte anos atrás, as pessoas ainda argumentavam que " +"programar em assembly era melhor do que programar em uma linguagem de alto " +"nível porque produzia um código que era dez vezes mais rápido. Hoje, a queda " +"desse argumento é óbvia - assim como os paralelos com o design de algorítimo " +"e a generalização de código." + +#. (itstool) path: sect1/title +#: article.translate.xml:136 +msgid "VM Objects" +msgstr "Objetos de VM" + +#. (itstool) path: sect1/para +#: article.translate.xml:138 +msgid "" +"The best way to begin describing the FreeBSD VM system is to look at it from " +"the perspective of a user-level process. Each user process sees a single, " +"private, contiguous VM address space containing several types of memory " +"objects. These objects have various characteristics. Program code and " +"program data are effectively a single memory-mapped file (the binary file " +"being run), but program code is read-only while program data is copy-on-" +"write. Program BSS is just memory allocated and filled with zeros on demand, " +"called demand zero page fill. Arbitrary files can be memory-mapped into the " +"address space as well, which is how the shared library mechanism works. Such " +"mappings can require modifications to remain private to the process making " +"them. The fork system call adds an entirely new dimension to the VM " +"management problem on top of the complexity already given." +msgstr "" +"A melhor maneira de começar a descrever o sistema de VM do FreeBSD é examiná-" +"lo da perspectiva de um processo em nível de usuário. Cada processo do " +"usuário vê um espaço de endereço de VM único, privado e contíguo, contendo " +"vários tipos de objetos de memória. Esses objetos possuem várias " +"características. O código do programa e os dados do programa são " +"efetivamente um único arquivo mapeado na memória (o arquivo binário sendo " +"executado), mas o código do programa é read-only enquanto os dados do " +"programa são copy-on-write. O programa BSS é apenas memória alocada e " +"preenchida com zeros sob demanda, chamado de demanda de preenchimento de " +"página com zero. Arquivos arbitrários também podem ser mapeados na memória " +"dentro do espaço de endereçamento como bem entender, que é como o mecanismo " +"de biblioteca compartilhada funciona. Esses mapeamentos podem exigir " +"modificações para permanecerem privados para o processo que os produz. A " +"chamada do sistema de fork adiciona uma dimensão totalmente nova ao problema " +"de gerenciamento de VMs além da complexidade já fornecida." + +#. (itstool) path: sect1/para +#: article.translate.xml:152 +msgid "" +"A program binary data page (which is a basic copy-on-write page) illustrates " +"the complexity. A program binary contains a preinitialized data section " +"which is initially mapped directly from the program file. When a program is " +"loaded into a process's VM space, this area is initially memory-mapped and " +"backed by the program binary itself, allowing the VM system to free/reuse " +"the page and later load it back in from the binary. The moment a process " +"modifies this data, however, the VM system must make a private copy of the " +"page for that process. Since the private copy has been modified, the VM " +"system may no longer free it, because there is no longer any way to restore " +"it later on." +msgstr "" +"Uma página de dados binários do programa (que é uma página básica de copy-on-" +"write) ilustra a complexidade. Um programa binário contém uma seção de dados " +"pré-inicializada que é inicialmente mapeada diretamente a partir do arquivo " +"de programa. Quando um programa é carregado no espaço de VM de um processo, " +"esta área é inicialmente mapeada na memória e suportada pelo próprio binário " +"do programa, permitindo que o sistema de VM liberte/reutilize a página e " +"depois carregue-a de volta a partir do binário. No entanto, no momento em " +"que um processo modifica esses dados, o sistema de VM deve fazer uma cópia " +"privada da página para esse processo. A partir do momento que a cópia " +"privada tenha sido modificada, o sistema de VM pode não mais liberá-la, " +"porque não há mais como restaurá-la depois." + +#. (itstool) path: sect1/para +#: article.translate.xml:163 +msgid "" +"You will notice immediately that what was originally a simple file mapping " +"has become much more complex. Data may be modified on a page-by-page basis " +"whereas the file mapping encompasses many pages at once. The complexity " +"further increases when a process forks. When a process forks, the result is " +"two processes—each with their own private address spaces, including any " +"modifications made by the original process prior to the call to " +"fork(). It would be silly for the VM system to make a " +"complete copy of the data at the time of the fork() " +"because it is quite possible that at least one of the two processes will " +"only need to read from that page from then on, allowing the original page to " +"continue to be used. What was a private page is made copy-on-write again, " +"since each process (parent and child) expects their own personal post-fork " +"modifications to remain private to themselves and not effect the other." +msgstr "" +"Você notará imediatamente que o que originalmente era um mapeamento de " +"arquivo simples se tornou muito mais complexo. Os dados podem ser " +"modificados página a página, enquanto o mapeamento de arquivos abrange " +"muitas páginas de uma só vez. A complexidade aumenta ainda mais quando " +"existe um fork do processo. Quando um processo se duplica, o resultado são " +"dois processos - cada um com seus próprios espaços de endereçamento " +"privados, incluindo quaisquer modificações feitas pelo processo original " +"antes de chamar um fork(). Seria bobagem o sistema de " +"VM fizesse uma cópia completa dos dados no momento do fork() porque é bem possível que pelo menos um dos dois processos precise " +"apenas ler essa página a partir de então, permitindo que a página original " +"continue a ser usada. O que era uma página privada é feito um copy-on-write " +"novamente, já que cada processo (pai e filho) espera que suas próprias " +"modificações pós-fork permaneçam privadas para si mesmas e não afetem a " +"outra." + +#. (itstool) path: sect1/para +#: article.translate.xml:178 +msgid "" +"FreeBSD manages all of this with a layered VM Object model. The original " +"binary program file winds up being the lowest VM Object layer. A copy-on-" +"write layer is pushed on top of that to hold those pages which had to be " +"copied from the original file. If the program modifies a data page belonging " +"to the original file the VM system takes a fault and makes a copy of the " +"page in the higher layer. When a process forks, additional VM Object layers " +"are pushed on. This might make a little more sense with a fairly basic " +"example. A fork() is a common operation for any *BSD " +"system, so this example will consider a program that starts up, and forks. " +"When the process starts, the VM system creates an object layer, let's call " +"this A:" +msgstr "" +"O FreeBSD gerencia tudo isso com um modelo de objetos de VM em camadas. O " +"arquivo de programa binário original acaba sendo a camada de objeto de VM " +"mais baixa. Uma camada copy-on-write é colocada acima dela para conter as " +"páginas que tiveram que ser copiadas do arquivo original. Se o programa " +"modificar uma página de dados pertencente ao arquivo original, o sistema de " +"VM assumirá que existe uma falha e fará uma cópia da página na camada " +"superior. Quando existe um fork do processo, as camadas adicionais de " +"objetos de VM são ativadas. Isso pode fazer um pouco mais de sentido com um " +"exemplo bastante básico. Um fork() é uma operação comum " +"para qualquer sistema *BSD, então este exemplo irá considerar um programa " +"que inicia e é feito um fork. Quando o processo é iniciado, o sistema de VM " +"cria uma camada de objeto, vamos chamar isso de A:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:192 +msgctxt "_" +msgid "external ref='fig1' md5='__failed__'" +msgstr "external ref='fig1' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:196 +#, no-wrap +msgid "" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/mediaobject +#: article.translate.xml:190 +msgid "" +" <_:" +"literallayout-1/> A picture " +msgstr "" +" <_:" +"literallayout-1/> A picture " + +#. (itstool) path: sect1/para +#: article.translate.xml:206 +msgid "" +"A represents the file—pages may be paged in and out of the file's physical " +"media as necessary. Paging in from the disk is reasonable for a program, but " +"we really do not want to page back out and overwrite the executable. The VM " +"system therefore creates a second layer, B, that will be physically backed " +"by swap space:" +msgstr "" +"A representa o arquivo - as páginas podem ser paginadas dentro e fora da " +"mídia física do arquivo, conforme necessário. Paginar a partir do disco é " +"razoável para um programa, mas nós realmente não queremos voltar atrás e " +"sobrescrever o executável. O sistema de VM, portanto, cria uma segunda " +"camada, B, que será fisicamente suportada pelo espaço de troca:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:214 +msgctxt "_" +msgid "external ref='fig2' md5='__failed__'" +msgstr "external ref='fig2' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:218 +#, no-wrap +msgid "" +"+---------------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+---------------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/para +#: article.translate.xml:226 +msgid "" +"On the first write to a page after this, a new page is created in B, and its " +"contents are initialized from A. All pages in B can be paged in or out to a " +"swap device. When the program forks, the VM system creates two new object " +"layers—C1 for the parent, and C2 for the child—that rest on top of B:" +msgstr "" +"Na primeira escrita em uma página depois disso, uma nova página é criada em " +"B e seu conteúdo é inicializado a partir de A. Todas as páginas em B podem " +"ser paginadas para dentro ou para fora por um dispositivo de troca. Quando é " +"feito o fork do programa, o sistema de VM cria duas novas camadas de objetos " +"- C1 para o processo pai e C2 para o filho - que ficam no topo de B:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:234 +msgctxt "_" +msgid "external ref='fig3' md5='__failed__'" +msgstr "external ref='fig3' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:238 +#, no-wrap +msgid "" +"+-------+-------+\n" +"| C1 | C2 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+-------+-------+\n" +"| C1 | C2 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/para +#: article.translate.xml:248 +msgid "" +"In this case, let's say a page in B is modified by the original parent " +"process. The process will take a copy-on-write fault and duplicate the page " +"in C1, leaving the original page in B untouched. Now, let's say the same " +"page in B is modified by the child process. The process will take a copy-on-" +"write fault and duplicate the page in C2. The original page in B is now " +"completely hidden since both C1 and C2 have a copy and B could theoretically " +"be destroyed if it does not represent a real file; however, " +"this sort of optimization is not trivial to make because it is so fine-" +"grained. FreeBSD does not make this optimization. Now, suppose (as is often " +"the case) that the child process does an exec(). Its " +"current address space is usually replaced by a new address space " +"representing a new file. In this case, the C2 layer is destroyed:" +msgstr "" +"Neste caso, digamos que uma página em B seja modificada pelo processo pai " +"original. O processo terá uma falha de copy-on-write e duplicará a página em " +"C1, deixando a página original em B intocada. Agora, digamos que a mesma " +"página em B seja modificada pelo processo filho. O processo assumirá uma " +"falha de copy-on-write e duplicará a página em C2. A página original em B " +"agora está completamente oculta, já que C1 e C2 têm uma cópia e B poderia, " +"teoricamente, ser destruído se não representasse um arquivo real; no entanto, esse tipo de otimização não é trivial de se fazer, " +"porque é muito refinado. O FreeBSD não faz essa otimização. Agora, suponha " +"(como é frequentemente o caso) que o processo filho execute um " +"exec(). Seu espaço de endereço atual é geralmente " +"substituído por um novo espaço de endereço representando um novo arquivo. " +"Nesse caso, a camada C2 é destruída:" + +#. (itstool) path: imageobject/imagedata +#. This is a reference to an external file such as an image or video. When +#. the file changes, the md5 hash will change to let you know you need to +#. update your localized copy. The msgstr is not used at all. Set it to +#. whatever you like once you have updated your copy of the file. +#: article.translate.xml:264 +msgctxt "_" +msgid "external ref='fig4' md5='__failed__'" +msgstr "external ref='fig4' md5='__failed__'" + +#. (itstool) path: textobject/literallayout +#: article.translate.xml:268 +#, no-wrap +msgid "" +"+-------+\n" +"| C1 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" +msgstr "" +"+-------+\n" +"| C1 |\n" +"+-------+-------+\n" +"| B |\n" +"+---------------+\n" +"| A |\n" +"+---------------+" + +#. (itstool) path: sect1/para +#: article.translate.xml:278 +msgid "" +"In this case, the number of children of B drops to one, and all accesses to " +"B now go through C1. This means that B and C1 can be collapsed together. Any " +"pages in B that also exist in C1 are deleted from B during the collapse. " +"Thus, even though the optimization in the previous step could not be made, " +"we can recover the dead pages when either of the processes exit or " +"exec()." +msgstr "" +"Neste caso, o número de filhos de B cai para um, e todos os acessos para B " +"passam agora por C1. Isso significa que B e C1 podem ser unidas. Todas as " +"páginas em B que também existem em C1 são excluídas de B durante a união. " +"Assim, mesmo que a otimização na etapa anterior não possa ser feita, podemos " +"recuperar as páginas mortas quando um dos processos finalizar ou executar um " +"exec()." + +#. (itstool) path: sect1/para +#: article.translate.xml:285 +msgid "" +"This model creates a number of potential problems. The first is that you can " *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Thu Sep 13 08:04:41 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E1C4B10A9726; Thu, 13 Sep 2018 08:04:40 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64B1685CBE; Thu, 13 Sep 2018 08:04:40 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5F9B512CDB; Thu, 13 Sep 2018 08:04:40 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8D84eev053592; Thu, 13 Sep 2018 08:04:40 GMT (envelope-from gahr@FreeBSD.org) Received: (from gahr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8D84eGS053591; Thu, 13 Sep 2018 08:04:40 GMT (envelope-from gahr@FreeBSD.org) Message-Id: <201809130804.w8D84eGS053591@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gahr set sender to gahr@FreeBSD.org using -f From: Pietro Cerutti Date: Thu, 13 Sep 2018 08:04:40 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52253 - head/share/pgpkeys X-SVN-Group: doc-head X-SVN-Commit-Author: gahr X-SVN-Commit-Paths: head/share/pgpkeys X-SVN-Commit-Revision: 52253 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 08:04:41 -0000 Author: gahr (ports committer) Date: Thu Sep 13 08:04:39 2018 New Revision: 52253 URL: https://svnweb.freebsd.org/changeset/doc/52253 Log: Update my PGP key Modified: head/share/pgpkeys/gahr.key Modified: head/share/pgpkeys/gahr.key ============================================================================== --- head/share/pgpkeys/gahr.key Thu Sep 13 02:34:41 2018 (r52252) +++ head/share/pgpkeys/gahr.key Thu Sep 13 08:04:39 2018 (r52253) @@ -1,90 +1,91 @@ -uid Pietro Cerutti (The FreeBSD Project) -sub rsa4096/3AC8004B408BA46A 2013-09-23 [expires: 2018-09-22] +pub rsa4096/40993B5A4A8F3F12 2018-09-13 [SC] [expires: 2021-09-12] + Key fingerprint = 546D E77C FA14 CEA4 480A D7FA 4099 3B5A 4A8F 3F12 +uid Pietro Cerutti +uid Pietro Cerutti +sub rsa4096/628EAA09AA81154B 2018-09-13 [E] [expires: 2021-09-12] ]]> From owner-svn-doc-all@freebsd.org Thu Sep 13 08:32:25 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60951108008F; Thu, 13 Sep 2018 08:32:25 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 168E986B54; Thu, 13 Sep 2018 08:32:25 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 11656131BF; Thu, 13 Sep 2018 08:32:25 +0000 (UTC) (envelope-from gahr@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8D8WOij068719; Thu, 13 Sep 2018 08:32:24 GMT (envelope-from gahr@FreeBSD.org) Received: (from gahr@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8D8WOja068718; Thu, 13 Sep 2018 08:32:24 GMT (envelope-from gahr@FreeBSD.org) Message-Id: <201809130832.w8D8WOja068718@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gahr set sender to gahr@FreeBSD.org using -f From: Pietro Cerutti Date: Thu, 13 Sep 2018 08:32:24 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52254 - head/share/pgpkeys X-SVN-Group: doc-head X-SVN-Commit-Author: gahr X-SVN-Commit-Paths: head/share/pgpkeys X-SVN-Commit-Revision: 52254 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 08:32:25 -0000 Author: gahr (ports committer) Date: Thu Sep 13 08:32:24 2018 New Revision: 52254 URL: https://svnweb.freebsd.org/changeset/doc/52254 Log: Update my key after signign all uids with my old key Modified: head/share/pgpkeys/gahr.key Modified: head/share/pgpkeys/gahr.key ============================================================================== --- head/share/pgpkeys/gahr.key Thu Sep 13 08:04:39 2018 (r52253) +++ head/share/pgpkeys/gahr.key Thu Sep 13 08:32:24 2018 (r52254) @@ -62,30 +62,41 @@ SUQ9GDu0nDoiuf+eLsC2FeH5AqPzlLfITlajpD1nPkdK8bUNH70td+ 7InJPnTNr5z0d0oLLmOeOq9SIC+3WaI21I2B74EFL1DV40uUstorVbM28qi3Pc/4 WQS9AzOv+9R7XOws7f7ltJQ9QApz/h2yvSH8rZcOpi0zanbkXNYCG2hzPYaO2bKn prQBAdxq62yxm1s0ydimXH2Ud5BCpc8zY8tSHTniUSNjLg3Il40a4HywevtQp5lE -xQUkJDq2l51guQINBFuaF0ABEAD141oXw99FclbKXhIaMBSXFCZeRTTVamFskt6P -ZbFDQsORrmmxgZ7Yj/ojzPyFysTdAo86SxzxR4Cxgit39+Tp86ASSHRm5GthJOLV -emeVqQr1/DKrb4iakoHOpmVbMoBOEj51M/GDu/zTyuxRAnq0VYBOeIQRMpLQsy9V -bvMfdQiT8gOAIYYi4QSsy1x+5HQdX7itH9LasHb3MOUor7xRnUhMkD3eIsA97PpB -qQx7a1fL3bakweWn0NVe8ax0Y3AzltIUPFqPdoPXa7t6jDBcHFOClEkbQPgLh8oe -NIANi/DZejAUW3vHHQzKumdeGNYYtxMKKY0vqie8Y9PN6AHrbtMlV1g8hqRP1/bo -iESpz1drNOR9RkPrW6n2ZFmJNCelQu5u5y7RvwYDc64GZ/wpWMSteQDG27dgK6pa -flMAmezu0coKOGqH2pQW0Bhfx29keLMkKSMvwCNOeX19/WD2W6fLHePwDvCCNWdg -j2pJxiyFggZfWi+TDp/HOb39xlIbyDkBbU0qvs288Up4IFev774kZhRwga5YzQcH -SF2yf/SPcyJKSPduYhvmzOlwkTjFtd5ekfoD+zrbqrfY9+sn2vXSNj07xQpy0CuM -DstFECTsj6kad2+pQ09bpdX5cFbLQ9yNrraRuBkQcU3a9bnEWVkORBoC37W4pcn9 -/vf8ywARAQABiQI8BBgBCgAmFiEEVG3nfPoUzqRICtf6QJk7WkqPPxIFAluaF0AC -GwwFCQWjmoAACgkQQJk7WkqPPxJ+Ig/9Gv1LOCF1flchAlgyGf2r7umbQRWeyz0e -mHuJogunLGDJ5ZZ40ndmNKtUsChxi3niCQjcu7xeQjf+crSzq9AuZLO8XTURxR1R -NYcdBs2ctZOOgaB4uBKT75wXn/omJA5rHgaaSqnxiASjrFL9UAeDgfqAl5TyRSkE -kdbA0SSFg1dYRAnXTnyXJk9UVn8TCvidHr9jg6kY9tnW0bVuWrulo1yS+k2yBWEh -wGCzWIiUVFOOCYg656+kbm27HwLZ+vjFYhHyEDDLatH2KBekTEwvJxlyeegNu7/v -TTUyhhOhJ1BHU1xbEMIZMaIESIzFFvxLdazc9cDUwtl1QZF9KWx8aLJsyyQvjiX5 -0Y9hnxb/XlTqqKvtZ3EOS8VH+NViuyruFUQkwurB6MOSiu32fMonlAU3DwdjaNfo -1TBZlGxESNg/KdATyHLQV8mOxUFoZQRGchb3J15ZB4PN34TdhBdDjgMMAzpLOpRL -nhrqtZtZeH+NBRq4tg3AesFHl/8tLRcCsz1PYawPvrJU+RqjDvZU7qY0R8iPhIeJ -R5OkkHUQnRASuwdxN3DPMSkTBflx0G0BN3knwKSbvbV17LXlF2bi5n5JetMP5YrG -+pR0BUr9ECi9N/Pw850getw87wTGKT0slC9lq1lPc3CTUmBS5Q6njmZdonCJtghb -h7dMp8LG4EI= -=zZ/o +xQUkJDq2l51giQIzBBABCgAdFiEE2m3hBqW4VLhd2G1JrdDTjqGSCJ4FAluaHd4A +CgkQrdDTjqGSCJ4KOw//dUzhuF3HoHxNBdUmnzzXcIlVv0AfRobkXXaEhvjyqFVV +Ps3k2fTYe7lGlXIXmxQQDdqVCwZHyOrv4b9GUiKZh3YoqOk35Q5QgyeGJAfRbA5K +SBMne09+HLrdtcjRy54wt6dIwaHyMc/xT5iZ3b0OT81hezhAfi71Xm8GGfF+ASkb +6Jd7osFPvFXkcihJf7l6LMuBrZmP7Ns5ipV5JVVoE1nArLFic1s7qYkRS44zsZvQ +R6PjBmeeCznbm/qAUiu7voRaFa85cvsTEo4up/L+Z98bPuDRpT38Xdw1oO5eskIo +F7idK9GPcFnuK/4d+oWf/hhuWyW8K+Fd4rOOiYgnry+5dH1aEK5edCNCAWMCcqRl +Oxehzyh+Z0DGkuvB2pkOIqlbM7Lyy/4DX1DTVaLkdcKQ6ae/W4r+R30bdkcqjWDS +0YIOR0v+T2vt2+N0IjlqfNrQa/moL+mgu6pCKTwhiVkOhl6HjipnBX4/qNrJTA80 +EoP+qWVvgwi+okg3HITnFHlx9XNYYmMBmDnLbcoa6zEslYmw+HXU+YReuc5UC4PS +CF+WWjewdFyfHf1r5EaHG0/MK+CXSSptN9ZpBhpQLUv5+10l9n3Vu+Gqux+uD+3i +EHBEzGMXttLueReinIcW2Gut8sq6poZjGTzfzsrVku/6Ur7OxCjSyEJtlf+NHZ+5 +Ag0EW5oXQAEQAPXjWhfD30VyVspeEhowFJcUJl5FNNVqYWyS3o9lsUNCw5GuabGB +ntiP+iPM/IXKxN0CjzpLHPFHgLGCK3f35OnzoBJIdGbka2Ek4tV6Z5WpCvX8Mqtv +iJqSgc6mZVsygE4SPnUz8YO7/NPK7FECerRVgE54hBEyktCzL1Vu8x91CJPyA4Ah +hiLhBKzLXH7kdB1fuK0f0tqwdvcw5SivvFGdSEyQPd4iwD3s+kGpDHtrV8vdtqTB +5afQ1V7xrHRjcDOW0hQ8Wo92g9dru3qMMFwcU4KUSRtA+AuHyh40gA2L8Nl6MBRb +e8cdDMq6Z14Y1hi3EwopjS+qJ7xj083oAetu0yVXWDyGpE/X9uiIRKnPV2s05H1G +Q+tbqfZkWYk0J6VC7m7nLtG/BgNzrgZn/ClYxK15AMbbt2Arqlp+UwCZ7O7Rygo4 +aofalBbQGF/Hb2R4syQpIy/AI055fX39YPZbp8sd4/AO8II1Z2CPaknGLIWCBl9a +L5MOn8c5vf3GUhvIOQFtTSq+zbzxSnggV6/vviRmFHCBrljNBwdIXbJ/9I9zIkpI +925iG+bM6XCROMW13l6R+gP7Otuqt9j36yfa9dI2PTvFCnLQK4wOy0UQJOyPqRp3 +b6lDT1ul1flwVstD3I2utpG4GRBxTdr1ucRZWQ5EGgLftbilyf3+9/zLABEBAAGJ +AjwEGAEKACYWIQRUbed8+hTOpEgK1/pAmTtaSo8/EgUCW5oXQAIbDAUJBaOagAAK +CRBAmTtaSo8/En4iD/0a/Us4IXV+VyECWDIZ/avu6ZtBFZ7LPR6Ye4miC6csYMnl +lnjSd2Y0q1SwKHGLeeIJCNy7vF5CN/5ytLOr0C5ks7xdNRHFHVE1hx0GzZy1k46B +oHi4EpPvnBef+iYkDmseBppKqfGIBKOsUv1QB4OB+oCXlPJFKQSR1sDRJIWDV1hE +CddOfJcmT1RWfxMK+J0ev2ODqRj22dbRtW5au6WjXJL6TbIFYSHAYLNYiJRUU44J +iDrnr6RubbsfAtn6+MViEfIQMMtq0fYoF6RMTC8nGXJ56A27v+9NNTKGE6EnUEdT +XFsQwhkxogRIjMUW/Et1rNz1wNTC2XVBkX0pbHxosmzLJC+OJfnRj2GfFv9eVOqo +q+1ncQ5LxUf41WK7Ku4VRCTC6sHow5KK7fZ8yieUBTcPB2No1+jVMFmUbERI2D8p +0BPIctBXyY7FQWhlBEZyFvcnXlkHg83fhN2EF0OOAwwDOks6lEueGuq1m1l4f40F +Gri2DcB6wUeX/y0tFwKzPU9hrA++slT5GqMO9lTupjRHyI+Eh4lHk6SQdRCdEBK7 +B3E3cM8xKRMF+XHQbQE3eSfApJu9tXXsteUXZuLmfkl60w/lisb6lHQFSv0QKL03 +8/DznSB63DzvBMYpPSyUL2WrWU9zcJNSYFLlDqeOZl2icIm2CFuHt0ynwsbgQg== +=hY7g -----END PGP PUBLIC KEY BLOCK----- ]]> From owner-svn-doc-all@freebsd.org Thu Sep 13 15:59:45 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC6D81091C04; Thu, 13 Sep 2018 15:59:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8064176EA9; Thu, 13 Sep 2018 15:59:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5CDC817ABE; Thu, 13 Sep 2018 15:59:44 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8DFxihG093918; Thu, 13 Sep 2018 15:59:44 GMT (envelope-from gjb@FreeBSD.org) Received: (from gjb@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8DFxhRe093916; Thu, 13 Sep 2018 15:59:43 GMT (envelope-from gjb@FreeBSD.org) Message-Id: <201809131559.w8DFxhRe093916@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: gjb set sender to gjb@FreeBSD.org using -f From: Glen Barber Date: Thu, 13 Sep 2018 15:59:43 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52255 - in head/en_US.ISO8859-1/htdocs/releases: 10.4R 11.2R X-SVN-Group: doc-head X-SVN-Commit-Author: gjb X-SVN-Commit-Paths: in head/en_US.ISO8859-1/htdocs/releases: 10.4R 11.2R X-SVN-Commit-Revision: 52255 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2018 15:59:45 -0000 Author: gjb Date: Thu Sep 13 15:59:43 2018 New Revision: 52255 URL: https://svnweb.freebsd.org/changeset/doc/52255 Log: Regen after r338650. Sponsored by: The FreeBSD Foundation Modified: head/en_US.ISO8859-1/htdocs/releases/10.4R/errata.html head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html Modified: head/en_US.ISO8859-1/htdocs/releases/10.4R/errata.html ============================================================================== --- head/en_US.ISO8859-1/htdocs/releases/10.4R/errata.html Thu Sep 13 08:32:24 2018 (r52254) +++ head/en_US.ISO8859-1/htdocs/releases/10.4R/errata.html Thu Sep 13 15:59:43 2018 (r52255) @@ -1,5 +1,5 @@ -FreeBSD 10.4-RELEASE Errata

    FreeBSD 10.4-RELEASE Errata

    The FreeBSD Project

    Copyright © 2018 The FreeBSD Documentation +FreeBSD 10.4-RELEASE Errata

    FreeBSD 10.4-RELEASE Errata

    The FreeBSD Project

    Copyright © 2018 The FreeBSD Documentation Project

    FreeBSD is a registered trademark of the FreeBSD Foundation.

    Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered @@ -13,7 +13,7 @@ as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the - “®” symbol.

    Last modified on 2018-05-08 14:03:08 EDT by gjb.
    Abstract

    This document lists errata items for FreeBSD 10.4-RELEASE, + “®” symbol.

    Last modified on 2018-09-13 11:58:04 EDT by gjb.
    Abstract

    This document lists errata items for FreeBSD 10.4-RELEASE, containing significant information discovered after the release or too late in the release cycle to be otherwise included in the release documentation. This information @@ -44,7 +44,7 @@ reassembly

    FreeBSD-SA-18:09.l1tf14 August 2018

    L1 Terminal Fault (L1TF) Kernel Information Disclosure

    FreeBSD-SA-18:10.ip14 August 2018

    Resource exhaustion in IP fragment reassembly

    FreeBSD-SA-18:11.hostapd14 August 2018

    Unauthenticated EAPOL-Key Decryption - Vulnerability

    3. Errata Notices

    ErrataDateTopic
    FreeBSD-EN-17:09.tzdata2 November 2017

    Timezone database information + Vulnerability

    FreeBSD-SA-18:12.elf12 September 2018

    Improper ELF header parsing

    3. Errata Notices

    ErrataDateTopic
    FreeBSD-EN-17:09.tzdata2 November 2017

    Timezone database information update

    FreeBSD-EN-18:01.tzdata07 March 2018

    Timezone database information update

    FreeBSD-EN-18:02.file07 March 2018

    Stack-based buffer overflow

    FreeBSD-EN-18:03.tzdata04 April 2018

    Update timezone database information

    FreeBSD-EN-18:04.mem04 April 2018

    Multiple small kernel memory Modified: head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html ============================================================================== --- head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html Thu Sep 13 08:32:24 2018 (r52254) +++ head/en_US.ISO8859-1/htdocs/releases/11.2R/errata.html Thu Sep 13 15:59:43 2018 (r52255) @@ -13,7 +13,7 @@ as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the “™” or the - “®” symbol.

    Last modified on 2018-09-11 11:00:17 EDT by gjb.
    Abstract

    This document lists errata items for FreeBSD 11.2-RELEASE, + “®” symbol.

    Last modified on 2018-09-13 11:57:11 EDT by gjb.
    Abstract

    This document lists errata items for FreeBSD 11.2-RELEASE, containing significant information discovered after the release or too late in the release cycle to be otherwise included in the release documentation. This information @@ -38,7 +38,7 @@ reassembly

    FreeBSD-SA-18:09.l1tf14 August 2018

    L1 Terminal Fault (L1TF) Kernel Information Disclosure

    FreeBSD-SA-18:10.ip14 August 2018

    Resource exhaustion in IP fragment reassembly

    FreeBSD-SA-18:11.hostapd14 August 2018

    Unauthenticated EAPOL-Key Decryption - Vulnerability

    3. Errata Notices

    ErrataDateTopic
    No erratas  

    4. Open Issues

    • FreeBSD/i386 installed on ZFS may crash during boot + Vulnerability

      FreeBSD-SA-18:12.elf12 September 2018

      Improper ELF header parsing

    3. Errata Notices

    ErrataDateTopic
    FreeBSD-EN-18:08.lazyfpu12 September 2018

    Regression in Lazy FPU remediati on

    4. Open Issues

    • FreeBSD/i386 installed on ZFS may crash during boot when the ZFS pool mount is attempted while booting an unmodified GENERIC kernel.

      A system tunable has been added as of revision r286584 to make the From owner-svn-doc-all@freebsd.org Fri Sep 14 02:11:57 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 208EC10A0F2F; Fri, 14 Sep 2018 02:11:57 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CA4B570147; Fri, 14 Sep 2018 02:11:56 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C4CC31E08D; Fri, 14 Sep 2018 02:11:56 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8E2Bumh015648; Fri, 14 Sep 2018 02:11:56 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8E2Bu0C015644; Fri, 14 Sep 2018 02:11:56 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809140211.w8E2Bu0C015644@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Fri, 14 Sep 2018 02:11:56 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52256 - in head/pt_BR.ISO8859-1/articles: . pam X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/articles: . pam X-SVN-Commit-Revision: 52256 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 02:11:57 -0000 Author: ebrandi Date: Fri Sep 14 02:11:55 2018 New Revision: 52256 URL: https://svnweb.freebsd.org/changeset/doc/52256 Log: pt_BR.ISO8859-1/articles/pam: New pt_BR translation into .po format * content synchronized with en_US document (rev 48488) * article.xml converted to .po * .po file was translated to pt_BR * .po and .xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/pam/ head/pt_BR.ISO8859-1/articles/pam/Makefile (contents, props changed) head/pt_BR.ISO8859-1/articles/pam/article.xml (contents, props changed) head/pt_BR.ISO8859-1/articles/pam/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/Makefile Modified: head/pt_BR.ISO8859-1/articles/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile Thu Sep 13 15:59:43 2018 (r52255) +++ head/pt_BR.ISO8859-1/articles/Makefile Fri Sep 14 02:11:55 2018 (r52256) @@ -21,6 +21,7 @@ SUBDIR+= linux-users SUBDIR+= mailing-list-faq SUBDIR+= nanobsd SUBDIR+= new-users +SUBDIR+= pam SUBDIR+= port-mentor-guidelines SUBDIR+= pr-guidelines SUBDIR+= problem-reports Added: head/pt_BR.ISO8859-1/articles/pam/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/pam/Makefile Fri Sep 14 02:11:55 2018 (r52256) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: PAM + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/pam/article.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/pam/article.xml Fri Sep 14 02:11:55 2018 (r52256) @@ -0,0 +1,1333 @@ + + + +

      + Módulos de Autenticação Plugáveis + + + + Esse artigo descreve princípios subjacentes e mecanismos da biblioteca de Módulos de Autenticação Plugáveis (PAM), e explica como configurar, como integrar com outras aplicações e como escrever novos módulos. + + + 2001 2002 2003 Networks Associates Technology, Inc. + + + Dag-ErlingSmørgravContributed by + + + + This article was written for the FreeBSD Project by ThinkSec AS and Network Associates Laboratories, the Security Research Division of Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 (CBOSS), as part of the DARPA CHATS research program. + + + + FreeBSD is a registered trademark of the FreeBSD Foundation. + Linux is a registered trademark of Linus Torvalds. + Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries. + Sun, Sun Microsystems, Java, Java Virtual Machine, JDK, JRE, JSP, JVM, Netra, OpenJDK, Solaris, StarOffice, SunOS and VirtualBox are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. + + + $FreeBSD$ + + +
      + Introdução + + A biblioteca dos Módulos de Autenticação Plugáveis (PAM) é uma API generalizada para serviços relacionados com autenticações as quais permitem ao administrador de sistema adicionar um novo método de autenticação simplesmente pela instalação de um novo módulo PAM, e modificar a política de autenticação pela edição do arquivo de configuração. + + O PAM foi definido e desenvolvido em 1995 por Vipin Samar e Charlie Lai da Sun Microsystems, e não teve muitas mudanças até hoje. Em 1997, o Open Group publicou a especificação preliminar do X/Open Single Sign-on (XSSO), a qual padroniza a API do PAM e adiciona extensões para autenticação única ou integrada. No momento da redação deste documento, esta especificação ainda não tinha sido adotada como padrão. + + Apesar deste artigo focar primariamente no sistema FreeBSD 5.x, o qual usa o OpenPAM, ele poderá ser igualmente aplicado ao FreeBSD 4.x, o qual usa o Linux-PAM, e a outros systemas operacionais, tais como o Linux e o Solaris. +
      + +
      + Termos e convenções + +
      + Definições + + A terminologia em torno do PAM é bastante confusa. Nem o artigo original de Neither Samar e Lai nem a especificação original do XSSO fizeram algum esforço para definir formalmente os termos de vários atores e entidades envolvidas no PAM, e os termos que eles usam (mas não definem) são algumas vezes duvidosos ou ambíguos. A primeira tentativa de estabelecer uma terminologia consistente e não ambígua foi feita no artigo escrito por Andrew G. Morgan (autor do Linux-PAM) em 1999. A escolha da terminologia de Morgan foi um grande avanço, mas na opinião deste autor, não é perfeita. O que segue é uma tentativa, fortemente inspirada por Morgan, de definir termos precisos e não ambíguos para todos os atores e entidades envolvidas no PAM. + + + + conta (account) + + Um conjunto de credenciais que o requerente está solicitando ao mediador. + + + + + requerente (applicant) + + Usuário ou entidade que solicita autenticação + + + + + Mediador (arbitrator) + + Usuário ou entidade a qual tem privilégios necessários para verificar as credenciais do requerente e autorizar ou não a solicitação + + + + + chain + + Uma sequência de módulos que irá ser chamada em resposta a uma solicitação do PAM. A chain inclui informações sobre a ordem a qual invocar os módulos, quais argumentos foram passados e como interpretar os resultados. + + + + + client + + A aplicação responsável por inicializar uma solicitação de autenticação em nome do requerente para obter as informações necessárias da autenticação dele. + + + + + recursos + + Um dos quatro grupos básicos de funcionalidades fornecidos pelo PAM: autenticação, gerenciamento de conta, gerenciamento de sessão e atualização de token de autenticação. + + + + + módulo + + Uma coleção de uma ou mais funções relacionadas implementando um recurso de autenticação específico, reunidas em um único arquivo binário (normalmente carregável dinamicamente) e identificadas por um único nome. + + + + + política + + O conjunto completo de instruções de configuração que descrevem como lidar com solicitações do PAM para um serviço específico. Uma política normalmente consiste em quatro chains, uma para cada recurso, embora alguns serviços não utilizem os quatro recursos. + + + + + servidor + + O aplicativo agindo em nome do mediador para conversar com o cliente, recuperar informações de autenticação, verificar as credenciais do requerente e conceder ou negar solicitações. + + + + + serviço + + Classe de servidores que provêm recursos similares ou relacionados e requerem autenticação similar. As políticas do PAM são definidas por serviço, portanto, todos os servidores que reivindicam o mesmo nome de serviço estarão sujeitos à mesma política. + + + + + sessão + + O contexto com o qual serviços são apresentados para o requerente pelo servidor. Um dos quatro recursos do PAM, gerenciamento de sessão, é concedido exclusivamente configurando e derrubando esse contexto. + + + + + token + + Um pedaço de informação associada à conta, como uma senha sendo uma palavra ou uma frase, que o solicitante deve fornecer para provar sua identidade. + + + + + transação + + Uma sequência de solicitações do mesmo requerente para a mesma instância do mesmo servidor, começando com a configuração de autenticação e sessão e terminando com a desmontagem da sessão. + + + +
      + +
      + Exemplos de uso + + Esta seção tem como objetivo ilustrar os significados de alguns dos termos definidos acima por meio de alguns exemplos simples. + +
      + O cliente e o servidor são um + + Este exemplo simples mostra alice usando su1 para se tornar root. + +% whoami +alice +% ls -l `which su` +-r-sr-xr-x 1 root wheel 10744 Dec 6 19:06 /usr/bin/su +% su - +Password: xi3kiune +# whoami +root + + + + + O requerente é alice. + + + A conta é root. + + + O processo su1 é ao mesmo tempo, o cliente e o servidor. + + + O token de autenticação é xi3kiune. + + + O mediador é root, e é por isso que su1 possui setuid para root. + + +
      + +
      + O cliente e o servidor são separados + + O exemplo abaixo mostra eve tentar iniciar uma conexão ssh1 com login.example.com, solicitar para efetuar login como bob e ter exito. Bob deveria ter escolhido uma senha melhor! + +% whoami +eve +% ssh bob@login.example.com +bob@login.example.com's password: god +Last login: Thu Oct 11 09:52:57 2001 from 192.168.0.1 +Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 + The Regents of the University of California. All rights reserved. +FreeBSD 4.4-STABLE (LOGIN) #4: Tue Nov 27 18:10:34 PST 2001 + +Welcome to FreeBSD! +% + + + + O requerente é eve. + + + O cliente é o processo ssh1 de Eve. + + + O servidor é o processo sshd8 em login.example.com + + + A conta é bob. + + + O token de autenticação é god. + + + Embora isso não seja mostrado neste exemplo, o mediador é root. + + +
      + +
      + Exemplo de política + + A seguir, a política padrão do FreeBSD para sshd: + +sshd auth required pam_nologin.so no_warn +sshd auth required pam_unix.so no_warn try_first_pass +sshd account required pam_login_access.so +sshd account required pam_unix.so +sshd session required pam_lastlog.so no_fail +sshd password required pam_permit.so + + + + Esta política se aplica ao serviço sshd (que não é necessariamente restrito ao servidor sshd8). + + + auth, account, session e password são recursos. + + + pam_nologin.so, pam_unix.so, pam_login_access.so, pam_lastlog.so e pam_permit.so são módulos. Fica claro neste exemplo que o pam_unix.so fornece pelo menos dois recursos (autenticação e gerenciamento de conta). + + +
      +
      + + +
      + +
      + PAM Essencial + +
      + Recursos e primitivos + + A API do PAM oferece seis primitivas de autenticação diferentes agrupadas em quatro recursos, descritos abaixo. + + + + auth + + Autenticação. Este recurso se preocupa em autenticar o requerente e estabelecer as credenciais da conta. Ele fornece duas primitivas: + + + + pam_authenticate3 autentica o requerente, geralmente solicitando um token de autenticação e comparando-o com um valor armazenado em um banco de dados ou obtido de um servidor de autenticação. + + + + pam_setcred3 estabelece credenciais de conta, como ID de usuário, associação de grupo e limites de recursos. + + + + + + + account + + Gerenciamento de contas. Esse recurso lida com problemas de disponibilidade de conta não relacionados à autenticação, como restrições de acesso com base na hora do dia ou na carga de trabalho do servidor. Ele fornece uma única primitiva: + + + + pam_acct_mgmt3 verifica se a conta solicitada está disponível. + + + + + + + session + + Gerenciamento de sessão. Esse recurso lida com tarefas associadas à configuração e desmontagem da sessão, como a contabilização de login. Ele fornece duas primitivas: + + + + pam_open_session3 executa tarefas associadas à configuração da sessão: adiciona uma entrada nos bancos de dados utmp e wtmp, inicia um agente SSH, etc. + + + + pam_close_session3 executa tarefas associadas à desmontagem da sessão: adiciona uma entrada nos bancos de dados utmp e wtmp, pare o agente SSH, etc. + + + + + + + password + + Gerenciamento de senhas. Esse recurso é usado para alterar o token de autenticação associado a uma conta, porque expirou ou porque o usuário deseja alterá-lo. Ele fornece uma única primitiva: + + + + pam_chauthtok3 altera o token de autenticação, opcionalmente, verificando se é suficientemente difícil de adivinhar, se não foi usado anteriormente etc. + + + + + + +
      + +
      + Módulos + + Módulos são um conceito muito central no PAM; afinal, eles são os M no PAM. Um módulo PAM é um código de programa autocontido que implementa as primitivas em uma ou mais instalações para um mecanismo específico; possíveis mecanismos para o recurso de autenticação, por exemplo, incluem os bancos de dados de senhas UNIX, NIS, LDAP e Radius. + +
      + Nomeação de Módulos + + O FreeBSD implementa cada mecanismo em um único módulo, chamado pam_mechanism.so (por exemplo, pam_unix.so para o mecanismo UNIX. Outras implementações às vezes possuem módulos separados para instalações separadas e incluem o nome do recurso, bem como o nome do mecanismo no nome do módulo. Para citar um exemplo, Solaris tem um módulo pam_dial_auth.so.1 que é comumente usado para autenticar usuários de conexões discadas. +
      + +
      + Versionando Módulos + + A implementação original do PAM no FreeBSD, baseada no Linux-PAM, não utilizou números de versão para os módulos PAM. Isso normalmente causaria problemas com aplicativos legados, que poderiam estar vinculados a versões mais antigas das bibliotecas do sistema, pois não havia como carregar uma versão correspondente dos módulos necessários. + + O OpenPAM, por outro lado, procura por módulos que possuam o mesmo número de versão que a biblioteca PAM (atualmente 2), e só retorna a um módulo não versionado se nenhum módulo versionado puder ser carregado. Assim, os módulos legados podem ser fornecidos para aplicativos legados, permitindo que novos aplicativos (ou recém-construídos) aproveitem os módulos mais recentes. + + Embora os módulos PAM do Solaris normalmente tenham um número de versão, eles não são realmente versionados, porque o número é uma parte do nome do módulo e deve ser incluído na configuração. +
      +
      + +
      + Chains e Políticas + + Quando um servidor inicia uma transação PAM, a biblioteca PAM tenta carregar uma política para o serviço especificado na chamada pam_start3. A política especifica como as solicitações de autenticação devem ser processadas e definidas em um arquivo de configuração. Este é o outro conceito central no PAM: a possibilidade de o administrador ajustar a política de segurança do sistema (no sentido mais amplo da palavra) simplesmente editando um arquivo de texto. + + Uma política consiste em quatro cadeias, uma para cada uma dos quatro recursos do PAM. Cada chain é uma sequência de instruções de configuração, cada uma especificando um módulo para invocar, alguns parâmetros (opcionais) para passar para o módulo e um sinalizador de controle que descreve como interpretar o código de retorno do módulo. + + Entender os sinalizadores de controle é essencial para entender os arquivos de configuração do PAM. Existem quatro diferentes flags de controle: + + + + binding + + Se o módulo tiver exito e nenhum módulo anterior na chain tiver falhado, a chain será encerrada imediatamente e a solicitação será concedida. Se o módulo falhar, o resto da chain é executado, mas a solicitação é negada no final. + + Esta flag de controle foi introduzida pela Sun no Solaris9 (SunOS 5.9), e também é suportado pelo OpenPAM. + + + + + required + + Se o módulo tiver exito, o restante da chain será executada e a solicitação será concedida, a menos que algum outro módulo falhe. Se o módulo falhar, o restante da chain também será executado, mas a solicitação será negada no final. + + + + + requisite + + Se o módulo for tiver exito, o restante da chain será executado e a solicitação será concedida, a menos que algum outro módulo falhe. Se o módulo falhar, a chain será encerrada imediatamente e a solicitação será negada. + + + + + sufficient + + Se o módulo tiver exito e nenhum módulo anterior na chain tiver falhado, a chain será encerrada imediatamente e a solicitação será concedida. Se o módulo falhar, o módulo será ignorado e o resto da chain será executado. + + Como a semântica dessa flag pode ser um pouco confusa, especialmente quando ela é usada para o último módulo em uma chain, é recomendado que a flag de controle binding seja usada em seu lugar, se a implementação o suportar. + + + + + optional + + O módulo é executado, mas seu resultado é ignorado. Se todos os módulos em uma chain estiverem marcados como optional, todas as solicitações serão sempre concedidas. + + + + + Quando um servidor invoca uma das seis primitivas PAM, o PAM recupera a chain para o recurso ao qual a primitiva pertence, e invoca cada um dos módulos listados na chain, na ordem em que estão listados, até chegar ao fim ou determina que nenhum processamento adicional é necessário (porque um módulo binding ou sufficient teve exito, ou porque um módulo requisite falhou.) O pedido é concedido se e somente se pelo menos um módulo foi chamado e todos os módulos não opcionais tiveram exito. + + Note que é possível, embora não muito comum, ter o mesmo módulo listado várias vezes na mesma chain. Por exemplo, um módulo que procura nomes de usuário e senhas em um servidor de diretório pode ser chamado várias vezes com parâmetros diferentes, especificando diferentes servidores de diretórios para contato. O PAM trata diferentes ocorrências do mesmo módulo na mesma chain de módulos diferentes e não relacionados. +
      + +
      + Transações + + O ciclo de vida de uma transação típica do PAM é descrito abaixo. Observe que, se qualquer uma dessas etapas falhar, o servidor deverá informar uma mensagem de erro adequada ao cliente e anular a transação. + + + + Se necessário, o servidor obtém as credenciais do mediador por meio de um mecanismo independente do PAM - mais comumente em virtude de ter sido iniciado por root ou de ser setuid root. + + + + O servidor chama pam_start3 para inicializar a biblioteca PAM, especificar seu nome de serviço e a conta de destino e registrar uma função de conversação adequada. + + + + O servidor obtém várias informações relacionadas à transação (como o nome de usuário do requerente e o nome do host no qual o cliente é executado) e o envia ao PAM usando pam_set_item3. + + + + O servidor chama pam_authenticate3 para autenticar o requerente. + + + + O servidor chama pam_acct_mgmt3 para verificar se a conta solicitada está disponível e é válida. Se a senha estiver correta mas expirar, pam_acct_mgmt3 retornará PAM_NEW_AUTHTOK_REQD em vez de PAM_SUCCESS. + + + + Se a etapa anterior retornasse PAM_NEW_AUTHTOK_REQD, o servidor agora chamaria pam_chauthtok3 para forçar o cliente a alterar o token de autenticação para a conta solicitada. + + + + Agora que o requerente foi devidamente autenticado, o servidor chama pam_setcred3 para estabelecer as credenciais da conta solicitada. É capaz de fazer isso porque age em nome do mediador e possui as credenciais do madiador. + + + + Depois que as credenciais corretas forem estabelecidas, o servidor chamará pam_open_session3 para configurar a sessão. + + + + O servidor agora executa qualquer serviço solicitado pelo cliente - por exemplo, fornecer ao requerente um shell. + + + + Quando o servidor terminar de atender ao cliente, ele chamará pam_close_session3 para derrubar a sessão. + + + + Finalmente, o servidor chama pam_end3 para notificar a biblioteca PAM que ela esta pronta e que pode liberar quaisquer recursos alocados no curso da transação. + + +
      +
      + +
      + Configuração do PAM + +
      + Arquivos de política do PAM + +
      + O arquivo <filename>/etc/pam.conf</filename> + + O arquivo de política tradicional do PAM é /etc/pam.conf. Este arquivo contém todas as políticas do PAM para o seu sistema. Cada linha do arquivo descreve uma etapa em uma chain, conforme mostrado abaixo: + +login auth required pam_nologin.so no_warn + + Os campos estão, na ordem: nome do serviço, nome do recurso, flag de controle, nome do módulo e argumentos do módulo. Quaisquer campos adicionais são interpretados como argumentos adicionais do módulo. + + Uma chain separada é construída para cada par de serviço/recurso, portanto, embora a ordem na qual as linhas para o mesmo serviço e recurso apareçam seja significativa, a ordem na qual os serviços e recursos individuais são listados não é. Os exemplos no artigo original do PAM agruparam as linhas de configuração por recurso, e o suporte do Solaris ao pam.conf ainda faz isso, mas a configuração de ações do FreeBSD configura as linhas por serviço. De qualquer maneira está bem; De qualquer forma, faz o mesmo sentido. +
      + +
      + O diretório <filename>/etc/pam.d</filename> + + O OpenPAM e o Linux-PAM suportam um mecanismo de configuração alternativo, que é o mecanismo preferido no FreeBSD. Neste esquema, cada política está contida em um arquivo separado com o nome do serviço ao qual se aplica. Esses arquivos são armazenados em /etc/pam.d/. + + Esses arquivos de políticas por serviço possuem apenas quatro campos, em vez de cinco no pam.conf: o campo nome do serviço é omitido. Assim, em vez da linha de exemplo no pam.conf da seção anterior, a seguinte linha deve estar em /etc/pam.d/login: + +auth required pam_nologin.so no_warn + + Como consequência dessa sintaxe simplificada, é possível usar a mesma política para vários serviços vinculando cada nome de serviço a um mesmo arquivo de política. Por exemplo, para usar a mesma política para os serviços su e sudo, pode-se fazer o seguinte: + +# cd /etc/pam.d +# ln -s su sudo + + Isso funciona porque o nome do serviço é determinado a partir do nome do arquivo em vez de ser especificado no arquivo de políticas, portanto, o mesmo arquivo pode ser usado para vários serviços com nomes diferentes. + + Como a política de cada serviço é armazenada em um arquivo separado, o mecanismo pam.d também facilita a instalação de políticas adicionais para pacotes de software de terceiros. +
      + +
      + A ordem de pesquisa da política + + Como vimos acima, as políticas do PAM podem ser encontradas em vários lugares. O que acontece se as políticas para o mesmo serviço existirem em vários lugares? + + É essencial entender que o sistema de configuração do PAM está centrado em chains. + +
      +
      + +
      + Quebra de uma linha de configuração + + Como explicado em , cada linha em /etc/pam.conf consiste em quatro ou mais campos: o nome do serviço, o nome do recurso, a flag de controle, o nome do módulo e nenhum ou mais argumentos do módulo. + + O nome do serviço é geralmente (embora nem sempre) o nome do aplicativo ao qual a instrução se aplica. Se não tiver certeza, consulte a documentação do aplicativo individual para determinar qual nome de serviço ele usa. + + Note que se você usar /etc/pam.d/ em vez de /etc/pam.conf, o nome do serviço é especificado pelo nome do arquivo de política e omitido a partir das linhas de configuração atuais, que então começam com o nome da instalação. + + O recurso é uma das quatro palavras-chave do recurso descritas em . + + Da mesma forma, a flag de controle é uma das quatro palavras-chave descritas em , descrevendo como interpretar o código de retorno do módulo. O Linux-PAM suporta uma sintaxe alternativa que permite especificar a ação para associar com cada código de retorno possível, mas isso deve ser evitado, pois não é padrão e está intimamente ligado à forma como o Linux-PAM envia chamadas de serviço (que difere muito da maneira que Solaris e OpenPAM fazem isso). Não surpreendentemente, o OpenPAM não suporta esta sintaxe. +
      + +
      + Políticas + + Para configurar o PAM corretamente, é essencial entender como as políticas são interpretadas. + + Quando um aplicativo chama pam_start3, a biblioteca PAM carrega a diretiva do serviço especificado e constrói quatro chains de módulos (uma para cada recurso). Se uma ou mais dessas chains estiverem vazias, as chains correspondentes da política para o outro serviço são substituídas. + + Quando o aplicativo chama mais tarde uma das seis primitivas PAM, a biblioteca PAM recupera a chain para o recurso correspondente e chama a função de serviço apropriado em cada módulo listado na chain, na ordem em que foram listadas na configuração. Após cada chamada para uma função de serviço, o tipo de módulo e o código de erro retornado pela função de serviço são usados ​​para determinar o que acontece a seguir. Com algumas exceções, discutidas abaixo, a tabela a seguir se aplica: + + + Resumo de execução da chain de PAM + + + + + + + + + PAM_SUCCESS + PAM_IGNORE + other + + + + + binding + if (!fail) break; + - + fail = true; + + + required + - + - + fail = true; + + + requisite + - + - + fail = true; break; + + + sufficient + if (!fail) break; + - + - + + + optional + - + - + - + + + +
      + + Se fail for true no final de uma chain, ou quando um break for atingido, o dispatcher retornará o código de erro retornado pelo primeiro módulo que falhou. Caso contrário, retorna PAM_SUCCESS. + + A primeira exceção é que o código de erro PAM_NEW_AUTHTOK_REQD é tratado como um sucesso, exceto que se nenhum módulo falhar e pelo menos um módulo retornar PAM_NEW_AUTHTOK_REQD, o dispatcher retornará PAM_NEW_AUTHTOK_REQD. + + A segunda exceção é que pam_setcred3 trata os módulos binding e sufficient como se eles fossem required. + + A terceira e última exceção é que pam_chauthtok3 executa a chain inteira duas vezes (uma vez para verificações preliminares e uma vez para definir a senha), e na fase preliminar, ele trata os módulos binding e sufficient como se fossem required. +
      +
      + +
      + Módulos PAM do FreeBSD + +
      + <citerefentry><refentrytitle>pam_deny</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_deny8 é um dos módulos mais simples disponíveis; responde a qualquer pedido com PAM_AUTH_ERR. É útil para desabilitar rapidamente um serviço (adicioná-lo ao topo de cada chain) ou para encerrar chains de módulos sufficient. +
      + +
      + <citerefentry><refentrytitle>pam_echo</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_echo8 simplesmente passa seus argumentos para a função de conversação como uma mensagem PAM_TEXT_INFO. É principalmente útil para depuração, mas também pode servir para exibir mensagens como O acesso não autorizado será processado antes de iniciar o procedimento de autenticação. +
      + +
      + <citerefentry><refentrytitle>pam_exec</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_exec8 leva seu primeiro argumento a ser o nome de um programa a ser executado, e os argumentos restantes são passados ​​para esse programa como argumentos de linha de comando. Uma aplicação possível é usá-lo para executar um programa no momento do login, que monta o diretório pessoal do usuário. +
      + +
      + <citerefentry><refentrytitle>pam_ftpusers</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + The pam_ftpusers8 module +
      + +
      + <citerefentry><refentrytitle>pam_group</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_group8 aceita ou rejeita os requerentes com base em sua participação em um determinado grupo de arquivos (normalmente wheel para su1). Ele é destinado principalmente para manter o comportamento tradicional do su1 do BSD, mas tem muitos outros usos, como excluir determinados grupos de usuários de um serviço particular. +
      + +
      + <citerefentry><refentrytitle>pam_guest</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_guest8 permite logins convidados usando nomes de login fixos. Vários requerimentos podem ser colocados na senha, mas o comportamento padrão é permitir qualquer senha, desde que o nome de login seja o de uma conta de convidado. O módulo pam_guest8 pode ser facilmente utilizado para implementar logins FTP anônimos. +
      + +
      + <citerefentry><refentrytitle>pam_krb5</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_krb58 +
      + +
      + <citerefentry><refentrytitle>pam_ksu</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_ksu8 +
      + +
      + <citerefentry><refentrytitle>pam_lastlog</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_lastlog8 +
      + +
      + <citerefentry><refentrytitle>pam_login_access</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_login_access8 fornece uma implementação da primitiva de gerenciamento de contas que impõe as restrições de login especificadas na tabela login.access5. +
      + +
      + <citerefentry><refentrytitle>pam_nologin</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_nologin8 recusa logins não-root quando existe um /var/run/nologin. Este arquivo é normalmente criado por shutdown8 quando restam menos de cinco minutos até o horário de encerramento programado. +
      + +
      + <citerefentry><refentrytitle>pam_opie</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_opie8 implementa o método de autenticação opie4. O sistema opie4 é um mecanismo de desafio-resposta em que a resposta a cada desafio é uma função direta do desafio e uma frase-senha, então a resposta pode ser facilmente computada just in time por qualquer pessoa que possua a senha, eliminando a necessidade de listas de senhas. Além disso, como opie4 nunca reutiliza um desafio que tenha sido respondido corretamente, ele não é vulnerável a ataques de repetição. +
      + +
      + <citerefentry><refentrytitle>pam_opieaccess</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_opieaccess8 é um módulo complementar para pam_opie8. Sua finalidade é impor as restrições codificadas em opieaccess5, que regulam as condições sob as quais um usuário que normalmente se autenticaria usando opie4 tem permissão para usar métodos alternativos. Isso geralmente é usado para proibir o uso de autenticação de senha de hosts não confiáveis. + + Para ser eficaz, o módulo pam_opieaccess8 deve ser listado como requisite imediatamente após uma entrada sufficient para pam_opie8, e antes de qualquer outro módulo, na chain auth. +
      + +
      + <citerefentry><refentrytitle>pam_passwdqc</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_passwdqc8 +
      + +
      + <citerefentry><refentrytitle>pam_permit</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_permit8 é um dos módulos mais simples disponíveis; responde a qualquer pedido com PAM_SUCCESS. É útil como um espaço reservado para serviços onde uma ou mais chains estariam vazias. +
      + +
      + <citerefentry><refentrytitle>pam_radius</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_radius8 +
      + +
      + <citerefentry><refentrytitle>pam_rhosts</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_rhosts8 +
      + +
      + <citerefentry><refentrytitle>pam_rootok</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_rootok8 reporta sucesso se e somente se o ID do usuário real do processo que o chama (que é assumido como sendo executado pelo requerente) é 0. Isso é útil para serviços que não estão em rede, como su1 ou passwd1, para o qual o root deve ter acesso automático. +
      + +
      + <citerefentry><refentrytitle>pam_securetty</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_securetty8 +
      + +
      + <citerefentry><refentrytitle>pam_self</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_self8 reporta sucesso se, e somente se, os nomes do requerente coincidem com os da conta de destino. É mais útil para serviços que não estão em rede, como su1, onde a identidade do requerente pode ser facilmente verificada. +
      + +
      + <citerefentry><refentrytitle>pam_ssh</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_ssh8 fornece serviços de autenticação e de sessão. O serviço de autenticação permite que os usuários que tenham chaves secretas SSH protegidas por senha em seu diretório ~/.ssh se autentiquem digitando sua frase secreta. O serviço de sessão inicia o ssh-agent1 e o pré-carrega com as chaves que foram descriptografadas na fase de autenticação. Esse recurso é particularmente útil para logins locais, seja em X (usando xdm1 ou outro gerenciador de login X que reconhece o PAM ) ou no console. +
      + +
      + <citerefentry><refentrytitle>pam_tacplus</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_tacplus8 +
      + +
      + <citerefentry><refentrytitle>pam_unix</refentrytitle><manvolnum>8</manvolnum></citerefentry> + + O módulo pam_unix8 implementa a autenticação de senha UNIX tradicional, usando getpwnam3 para obter a senha da conta de destino e compará-la com a fornecida pelo requerente. Ele também fornece serviços de gerenciamento de conta (impondo tempos de expiração de conta e senha) e serviços de alteração de senha. Este é provavelmente o módulo mais útil, já que a grande maioria dos administradores desejará manter um comportamento histórico para pelo menos alguns serviços. +
      +
      + +
      + Programação de Aplicação PAM + + Esta seção ainda não foi escrita. + + + +
      + +
      + Programação de Módulos PAM + + Esta seção ainda não foi escrita. +
      + + + Exemplo de Aplicação PAM + + O que vem a seguir é uma implementação mínima de su1 utilizando o PAM. Observe que ele usa a função de conversa openpam_ttyconv3 específica do OpenPAM, que é prototipada em security/openpam.h . Se você deseja construir este aplicativo em um sistema com uma biblioteca PAM diferente, você terá que fornecer sua própria função de conversação. Uma função de conversa robusta é surpreendentemente difícil de implementar; o apresentado em é um bom ponto de partida, mas não deve ser usado em aplicações do mundo real. + +/*- + * Copyright (c) 2002,2003 Networks Associates Technology, Inc. + * All rights reserved. + * + * This software was developed for the FreeBSD Project by ThinkSec AS and + * Network Associates Laboratories, the Security Research Division of + * Network Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035 + * ("CBOSS"), as part of the DARPA CHATS research program. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * 3. The name of the author may not be used to endorse or promote + * products derived from this software without specific prior written + * permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $P4: //depot/projects/openpam/bin/su/su.c#10 $ + * $FreeBSD$ + */ + +#include <sys/param.h> +#include <sys/wait.h> + +#include <err.h> +#include <pwd.h> +#include <stdio.h> +#include <stdlib.h> +#include <string.h> +#include <syslog.h> +#include <unistd.h> + +#include <security/pam_appl.h> +#include <security/openpam.h> /* for openpam_ttyconv() */ + +extern char **environ; + +static pam_handle_t *pamh; +static struct pam_conv pamc; + +static void +usage(void) +{ + + fprintf(stderr, "Usage: su [login [args]]\n"); + exit(1); +} + +int +main(int argc, char *argv[]) +{ + char hostname[MAXHOSTNAMELEN]; + const char *user, *tty; + char **args, **pam_envlist, **pam_env; + struct passwd *pwd; + int o, pam_err, status; + pid_t pid; + + while ((o = getopt(argc, argv, "h")) != -1) + switch (o) { + case 'h': + default: + usage(); + } + + argc -= optind; + argv += optind; + + if (argc > 0) { + user = *argv; + --argc; + ++argv; + } else { + user = "root"; + } + + /* initialize PAM */ + pamc.conv = &openpam_ttyconv; + pam_start("su", user, &pamc, &pamh); + + /* set some items */ + gethostname(hostname, sizeof(hostname)); + if ((pam_err = pam_set_item(pamh, PAM_RHOST, hostname)) != PAM_SUCCESS) + goto pamerr; + user = getlogin(); + if ((pam_err = pam_set_item(pamh, PAM_RUSER, user)) != PAM_SUCCESS) + goto pamerr; + tty = ttyname(STDERR_FILENO); + if ((pam_err = pam_set_item(pamh, PAM_TTY, tty)) != PAM_SUCCESS) + goto pamerr; + + /* authenticate the applicant */ + if ((pam_err = pam_authenticate(pamh, 0)) != PAM_SUCCESS) + goto pamerr; + if ((pam_err = pam_acct_mgmt(pamh, 0)) == PAM_NEW_AUTHTOK_REQD) + pam_err = pam_chauthtok(pamh, PAM_CHANGE_EXPIRED_AUTHTOK); + if (pam_err != PAM_SUCCESS) + goto pamerr; + + /* establish the requested credentials */ + if ((pam_err = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS) + goto pamerr; + + /* authentication succeeded; open a session */ + if ((pam_err = pam_open_session(pamh, 0)) != PAM_SUCCESS) + goto pamerr; + + /* get mapped user name; PAM may have changed it */ + pam_err = pam_get_item(pamh, PAM_USER, (const void **)&user); + if (pam_err != PAM_SUCCESS || (pwd = getpwnam(user)) == NULL) + goto pamerr; + + /* export PAM environment */ + if ((pam_envlist = pam_getenvlist(pamh)) != NULL) { + for (pam_env = pam_envlist; *pam_env != NULL; ++pam_env) { + putenv(*pam_env); + free(*pam_env); + } + free(pam_envlist); + } + + /* build argument list */ + if ((args = calloc(argc + 2, sizeof *args)) == NULL) { + warn("calloc()"); + goto err; + } + *args = pwd->pw_shell; + memcpy(args + 1, argv, argc * sizeof *args); + + /* fork and exec */ + switch ((pid = fork())) { + case -1: + warn("fork()"); + goto err; + case 0: + /* child: give up privs and start a shell */ + + /* set uid and groups */ + if (initgroups(pwd->pw_name, pwd->pw_gid) == -1) { + warn("initgroups()"); + _exit(1); + } + if (setgid(pwd->pw_gid) == -1) { + warn("setgid()"); + _exit(1); + } + if (setuid(pwd->pw_uid) == -1) { + warn("setuid()"); *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Fri Sep 14 19:04:26 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AD47010913C7; Fri, 14 Sep 2018 19:04:26 +0000 (UTC) (envelope-from zeising@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 629598E00D; Fri, 14 Sep 2018 19:04:26 +0000 (UTC) (envelope-from zeising@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 5D8197E3; Fri, 14 Sep 2018 19:04:26 +0000 (UTC) (envelope-from zeising@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8EJ4QIu035978; Fri, 14 Sep 2018 19:04:26 GMT (envelope-from zeising@FreeBSD.org) Received: (from zeising@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8EJ4QqU035977; Fri, 14 Sep 2018 19:04:26 GMT (envelope-from zeising@FreeBSD.org) Message-Id: <201809141904.w8EJ4QqU035977@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: zeising set sender to zeising@FreeBSD.org using -f From: Niclas Zeising Date: Fri, 14 Sep 2018 19:04:26 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52257 - head/en_US.ISO8859-1/books/porters-handbook/uses X-SVN-Group: doc-head X-SVN-Commit-Author: zeising X-SVN-Commit-Paths: head/en_US.ISO8859-1/books/porters-handbook/uses X-SVN-Commit-Revision: 52257 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2018 19:04:26 -0000 Author: zeising Date: Fri Sep 14 19:04:25 2018 New Revision: 52257 URL: https://svnweb.freebsd.org/changeset/doc/52257 Log: Document USES=gl properly. Reviewed by: mat, bcr Differential Revision: https://reviews.freebsd.org/D17114 Modified: head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml Modified: head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml Fri Sep 14 02:11:55 2018 (r52256) +++ head/en_US.ISO8859-1/books/porters-handbook/uses/chapter.xml Fri Sep 14 19:04:25 2018 (r52257) @@ -689,6 +689,91 @@ build- and run-time dependencies. + + <literal>gl</literal> + + Possible arguments: (none) + + Provides an easy way to depend on + GL components. The components + should be listed in USE_GL. The available + components are: + + + + egl + + + add a library dependency on libEGL.so + from graphics/mesai-libs + + + + + gbm + + + Add a library dependency on libgbm.so + from graphics/mesa-libs + + + + + gl + + + Add a library dependency on libGL.so + from graphics/mesa-libs + + + + + glesv2 + + + Add a library dependency on libGLESv2.so + from graphics/mesa-libs + + + + + glew + + + Add a library dependency on libGLEW.so + from graphics/glew + + + + + glu + + + Add a library dependency on libGLU.so + from graphics/libGLU + + + + + glut + + + Add a library dependency on libglut.so + from graphics/freeglut + + + + + glw + + + Add a library dependency on libGLw.so + from graphics/libGLw + + + + + <literal>gmake</literal> From owner-svn-doc-all@freebsd.org Sat Sep 15 11:59:07 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3F8E10A4613; Sat, 15 Sep 2018 11:59:07 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 440B58A32D; Sat, 15 Sep 2018 11:59:07 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 3954C13166; Sat, 15 Sep 2018 11:59:07 +0000 (UTC) (envelope-from bhd@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8FBx7SC056599; Sat, 15 Sep 2018 11:59:07 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8FBx77s056598; Sat, 15 Sep 2018 11:59:07 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201809151159.w8FBx77s056598@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidotting Date: Sat, 15 Sep 2018 11:59:07 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52258 - head/de_DE.ISO8859-1/books/handbook/introduction X-SVN-Group: doc-head X-SVN-Commit-Author: bhd X-SVN-Commit-Paths: head/de_DE.ISO8859-1/books/handbook/introduction X-SVN-Commit-Revision: 52258 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 11:59:07 -0000 Author: bhd Date: Sat Sep 15 11:59:06 2018 New Revision: 52258 URL: https://svnweb.freebsd.org/changeset/doc/52258 Log: Update to r52007: Remove some not particularly recognizable websites. Modified: head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml Fri Sep 14 19:04:25 2018 (r52257) +++ head/de_DE.ISO8859-1/books/handbook/introduction/chapter.xml Sat Sep 15 11:59:06 2018 (r52258) @@ -4,7 +4,7 @@ The FreeBSD German Documentation Project $FreeBSD$ - basiert auf: r51981 + basiert auf: r52007 --> - Pair - Networks - Pair Networks - - - - Sony Japan Sony Japan @@ -789,22 +782,6 @@ NetEase - - - Weathernews - - Weathernews - - - - - TELEHOUSE - America - TELEHOUSE America - - - und viele weitere. Wikipedia pflegt eine Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9DCA10A7373; Sat, 15 Sep 2018 14:15:23 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F6538DB79; Sat, 15 Sep 2018 14:15:23 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 65F4B14838; Sat, 15 Sep 2018 14:15:23 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8FEFN3o028188; Sat, 15 Sep 2018 14:15:23 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8FEFMYH028185; Sat, 15 Sep 2018 14:15:22 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809151415.w8FEFMYH028185@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Sat, 15 Sep 2018 14:15:22 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52259 - in head/pt_BR.ISO8859-1/articles: . vinum X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/articles: . vinum X-SVN-Commit-Revision: 52259 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 14:15:24 -0000 Author: ebrandi Date: Sat Sep 15 14:15:22 2018 New Revision: 52259 URL: https://svnweb.freebsd.org/changeset/doc/52259 Log: pt_BR.ISO8859-1/articles/vinum: New pt_BR translation into .po format * content synchronized with en_US document (rev 50804) * article.xml converted to .po * .po file was translated to pt_BR * .po and .xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/vinum/ head/pt_BR.ISO8859-1/articles/vinum/Makefile (contents, props changed) head/pt_BR.ISO8859-1/articles/vinum/article.xml (contents, props changed) head/pt_BR.ISO8859-1/articles/vinum/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/Makefile Modified: head/pt_BR.ISO8859-1/articles/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile Sat Sep 15 11:59:06 2018 (r52258) +++ head/pt_BR.ISO8859-1/articles/Makefile Sat Sep 15 14:15:22 2018 (r52259) @@ -28,6 +28,7 @@ SUBDIR+= problem-reports SUBDIR+= rc-scripting SUBDIR+= remote-install SUBDIR+= solid-state +SUBDIR+= vinum SUBDIR+= vm-design DOC_PREFIX?= ${.CURDIR}/../.. Added: head/pt_BR.ISO8859-1/articles/vinum/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/vinum/Makefile Sat Sep 15 14:15:22 2018 (r52259) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: Vinum + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/vinum/article.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/vinum/article.xml Sat Sep 15 14:15:22 2018 (r52259) @@ -0,0 +1,695 @@ + + +
      + + + + O Gerenciador de Volume <filename>vinum</filename> + + + Greg Lehey Escrito originalmente por + + + + + Sinopse + + Não importa o tipo de disco, sempre há problemas em potencial. Os discos podem ser muito pequenos, muito lentos ou pouco confiáveis para atender aos requisitos do sistema. Enquanto os discos estão ficando maiores, também ficam maiores os requisitos para armazenamento de dados. Geralmente, é necessário um sistema de arquivos maior que a capacidade de um disco. Várias soluções para esses problemas foram propostas e implementadas. + + Um método é através do uso de vários discos, e às vezes discos redundantes. Além de suportar várias placas e controladoras para sistemas RAID (Redundant Array of Independent Disks), o sistema básico do FreeBSD inclui o gerenciador de volumes vinum, um driver de dispositivo de bloco que implementa discos virtuais e aborda esses três problemas. O vinum oferece mais flexibilidade, desempenho e confiabilidade do que o armazenamento em disco tradicional e implementa os modelos RAID-0, RAID-1 e RAID-5, tanto individualmente quanto combinados. + + Este capítulo fornece uma visão geral dos possíveis problemas com o armazenamento em disco tradicional e uma introdução ao gerenciador de volumes vinum. + + + Começando com o FreeBSD 5, o vinum foi reescrito para se encaixar na Arquitetura GEOM, mantendo as idéias originais, a terminologia e os metadados no disco. Esta reescrita é chamada gvinum (para GEOM vinum). Enquanto este capítulo usa o termo vinum, qualquer invocação de comandos deve ser executada com o gvinum. O nome do módulo do kernel mudou do original vinum.ko para geom_vinum.ko, e todos os device nodes residem em /dev/gvinum em vez de /dev/vinum. A partir do FreeBSD 6, a implementação original do vinum não está mais disponível no código base. + + + + + Gargalos de Acesso + + Sistemas modernos frequentemente precisam acessar dados de uma maneira altamente concorrente. Por exemplo, grandes servidores FTP ou HTTP podem manter milhares de sessões simultâneas e ter múltiplas conexões de 100 Mbit/s para o mundo externo, muito além da taxa de transferência sustentada da maioria dos discos. + + As unidades de disco atuais podem transferir dados sequencialmente a até 70 MB/s, mas esse valor é de pouca importância em um ambiente em que muitos processos independentes acessam uma unidade e onde podem obter apenas uma fração desses valores. Nesses casos, é mais interessante visualizar o problema do ponto de vista do subsistema de disco. O parâmetro importante é a carga que uma transferência coloca no subsistema ou o tempo pelo qual uma transferência ocupa as unidades envolvidas na transferência. + + Em qualquer transferência de disco, a unidade deve primeiro posicionar as cabeças, aguardar que o primeiro setor passe sob a cabeça de leitura e depois realizar a transferência. Essas ações podem ser consideradas atômicas, pois não faz sentido interrompê-las. + + Considere uma transferência típica de cerca de 10 kB: a geração atual de discos de alto desempenho pode posicionar as cabeças em uma média de 3,5 ms. As unidades mais rápidas giram a 15.000 rpm, portanto a latência rotacional média (meia revolução) é de 2 ms. A 70 MB/s, a própria transferência leva cerca de 150 μs, quase nada em comparação com o tempo de posicionamento. Nesse caso, a taxa de transferência efetiva cai para pouco mais de 1 MB/s e é claramente altamente dependente do tamanho da transferência. + + A solução tradicional e óbvia para esse gargalo é mais eixos: em vez de usar um disco grande, use vários discos menores com o mesmo espaço de armazenamento agregado. Cada disco é capaz de se posicionar e transferir de forma independente, portanto, o rendimento efetivo aumenta em um fator próximo ao número de discos usados. + + A melhoria real da taxa de transferência é menor que o número de discos envolvidos. Embora cada unidade seja capaz de transferir em paralelo, não há como garantir que as solicitações sejam distribuídas uniformemente pelas unidades. Inevitavelmente, a carga em uma unidade será maior que em outra. + + Concatenação de disco + Concatenação Vinum + + A uniformidade da carga nos discos é fortemente dependente da maneira como os dados são compartilhados entre as unidades. Na discussão a seguir, é conveniente pensar no armazenamento em disco como um grande número de setores de dados que são endereçáveis por número, mais ou menos como as páginas de um livro. O método mais óbvio é dividir o disco virtual em grupos de setores consecutivos do tamanho dos discos físicos individuais e armazená-los dessa maneira, mais ou menos como pegar um livro grande e dividi-lo em seções menores. Esse método é chamado de concatenação e tem a vantagem de os discos não precisarem ter nenhum relacionamento de tamanho específico. Ele funciona bem quando o acesso ao disco virtual é distribuído uniformemente sobre seu espaço de endereço. Quando o acesso é concentrado em uma área menor, a melhoria é menos acentuada. ilustra a seqüência na qual as unidades de armazen amento são alocadas em uma organização concatenada. + + +
      + Organização Concatenada + + + + + + +
      + + Discos Distribuídos + Discos Distribuídos no Vinum + RAID + + Um mapeamento alternativo é dividir o espaço de endereço em componentes menores e de tamanhos iguais e armazená-los sequencialmente em diferentes dispositivos. Por exemplo, os primeiros 256 setores podem ser armazenados no primeiro disco, os próximos 256 setores no próximo disco e assim por diante. Depois de preencher o último disco, o processo é repetido até que os discos estejam cheios. Este mapeamento é chamado striping ou RAID-0. + + O RAID oferece várias formas de tolerância a falhas, embora o RAID-0 seja um pouco enganador, pois não fornece redundância. O striping requer um pouco mais de esforço para localizar os dados e pode causar carga de I/O (INPUT/OUTPUT) adicional, onde uma transferência é distribuída por vários discos, mas também pode fornecer uma carga mais constante nos discos. ilustra a seqüência na qual as unidades de armazenamento são alocadas em uma organização distribuída. + + +
      + Organização do modo distribuido (Striped) + + + + + + +
      +       + + + Integridade de dados + + O problema final com os discos é que eles não são confiáveis. Embora a confiabilidade tenha aumentado tremendamente nos últimos anos, as unidades de disco ainda são o componente central mais provável de um servidor para falhar. Quando o fazem, os resultados podem ser catastróficos e substituir uma unidade de disco com falha e a restauração de dados pode resultar em tempo de inatividade do servidor. + + Espelhamento de disco + Espelhamento no Vinum + RAID-1 + + Uma abordagem para esse problema é o mirroring (espelhamento), ou RAID-1, que mantém duas cópias dos dados em diferentes hardwares físicos. Qualquer gravação no volume grava em ambos os discos; uma leitura pode ser satisfeita de qualquer um, portanto, se uma unidade falhar, os dados ainda estarão disponíveis na outra unidade. + + O mirroring tem dois problemas: + + + + Requer o dobro de armazenamento em disco que uma solução não redundante. + + + + As gravações devem ser executadas em ambas as unidades, então ela usa o dobro da largura de banda de um volume não espelhado. As leituras não sofrem uma penalidade de desempenho e podem até ser mais rápidas. + + + + RAID-5 + + Uma solução alternativa é a parity (paridade), implementada nos níveis RAID 2, 3, 4 e 5. Destes, o RAID-5 é o mais interessante. Como implementado no vinum, é uma variante em uma organização striped que dedica um bloco de cada distribuição à paridade de um dos outros blocos. Como implementado por vinum, um plex RAID-5 é semelhante a um plex striped, exceto que ele implementa RAID-5 incluindo um bloco de paridade em cada stripe. Conforme exigido pelo RAID-5, o local desse bloco de paridade muda de um stripe para o próximo. Os números nos blocos de dados indicam os números de blocos relativos. + + +
      + Organização <acronym>RAID</acronym>-5 + + + + + + +
      + + Comparado ao mirroring, o RAID-5 tem a vantagem de exigir significativamente menos espaço de armazenamento. O acesso de leitura é semelhante ao das organizações distribuídas, mas o acesso de gravação é significativamente mais lento, aproximadamente 25% do desempenho de leitura. Se uma unidade falhar, a matriz pode continuar a operar no modo degradado, onde uma leitura de uma das unidades acessíveis restantes continua normalmente, mas uma leitura da unidade com falha é recalculada a partir do bloco correspondente de todas as unidades restantes. +       + + + Objetos do <filename>vinum</filename> + + A fim de resolver estes problemas, o vinum implementa uma hierarquia de quatro níveis de objetos: + + + + O objeto mais visível é o disco virtual, chamado volume. Os volumes têm essencialmente as mesmas propriedades de uma unidade de disco UNIX, embora haja algumas pequenas diferenças. Por um lado, eles não têm limitações de tamanho. + + + + Os volumes são compostos de plexes, cada um dos quais representa o espaço de endereço total de um volume. Este nível na hierarquia fornece redundância. Pense em plexes como discos individuais em uma matriz espelhada, cada um contendo os mesmos dados. + + + + Como o vinum existe dentro do framework de armazenamento em disco UNIX, seria possível usar as partições UNIX como bloco de construção para plexes de vários discos. Na verdade, isso acaba sendo muito inflexível, pois os discos UNIX podem ter apenas um número limitado de partições. Em vez disso, o vinum subdivide uma única partição UNIX, a unidade, em áreas contíguas chamadas subdiscos , que são usados como blocos de construção para plexes. + + + + Subdiscos residem em vinum drives, atualmente partições UNIX. Unidades vinum podem conter qualquer número de subdiscos. Com exceção de uma pequena área no início da unidade, que é usada para armazenar informações de configuração e estado, a unidade inteira está disponível para armazenamento de dados. + + + + As seções a seguir descrevem a maneira como esses objetos fornecem a funcionalidade necessária do vinum. + + + Considerações sobre o tamanho do volume + + Os plexes podem incluir vários subdiscos distribuídos por todas as unidades na configuração vinum. Como resultado, o tamanho de uma unidade individual não limita o tamanho de um plex ou de um volume. + + + + Armazenamento de Dados Redundantes + + O vinum implementa o espelhamento anexando vários plexes a um volume. Cada plex é uma representação dos dados em um volume. Um volume pode conter entre um e oito plexes. + + Embora um plex represente os dados completos de um volume, é possível que partes da representação estejam fisicamente ausentes, seja por design (por não definir um subdisco para partes do plex) ou por acidente (como resultado da falha de representação). Contanto que pelo menos um plex possa fornecer os dados para o intervalo de endereços completo do volume, o volume estará totalmente funcional. + + + + Quais são as organizações disponíveis para um Plex? + + O vinum implementa a concatenação e o striping no nível plex: + + + + Um plex concatenado usa o espaço de endereço de cada subdisco um de cada vez. Plexes concatenados são os mais flexíveis, pois podem conter qualquer número de subdiscos e os subdiscos podem ser de tamanho diferente. O plex pode ser estendido adicionando subdiscos adicionais. Eles exigem menos tempo de CPU do que os plexes distribuídos, embora a diferença na sobrecarga de CPU não seja mensurável. Por outro lado, eles são mais suscetíveis a hot spots, nos quais um disco é muito ativo e outros ficam ociosos. + + + + Um plex striped distribui os dados uniformemente entre cada subdisco. Os subdiscos devem ser todos do mesmo tamanho e deve haver pelo menos dois subdiscos para distingui-los de um plex concatenado. A maior vantagem dos plexes striped é que eles reduzem os hot spots. Ao escolher uma faixa de tamanho ideal, de cerca de 256 kB, a carga pode ser nivelada nas unidades de componentes. Estender um complexo adicionando novos subdiscos é algo tão complicado que o vinum não o implementa. + + + + resume as vantagens e desvantagens de cada organização plex. + + + Organizações Plex do <filename>vinum</filename> + + + + + Tipo plex + Subdiscos mínimos + Pode adicionar subdiscos + Deve ser de tamanho igual + Aplicação + + + + + + concatenado + 1 + sim + não + Armazenamento de dados grandes com flexibilidade máxima de posicionamento e desempenho moderado + + + + striped + 2 + não + sim + Alto desempenho em combinação com acesso altamente concorrente + + + +
      +       +       + + + Alguns exemplos + + O vinum mantém um banco de dados de configuração que descreve os objetos conhecidos de um sistema individual. Inicialmente, o usuário cria o banco de dados de configuração a partir de um ou mais arquivos de configuração usando gvinum8. O vinum armazena uma cópia de seu banco de dados de configuração em cada dispositivo de disco sob seu controle. Este banco de dados é atualizado em cada mudança de estado, de modo que uma reinicialização restaura com precisão o estado de cada objeto vinum. + + + O arquivo de configuração + + O arquivo de configuração descreve objetos vinum individuais. A definição de um volume simples pode ser: + + drive a device /dev/da3h + volume myvol + plex org concat + sd length 512m drive a + + Este arquivo descreve quatro objetos vinum: + + + + A linha drive descreve uma partição de disco (drive) e sua localização relativa ao hardware subjacente. É dado o nome simbólico a. Essa separação de nomes simbólicos de nomes de dispositivos permite que os discos sejam movidos de um local para outro sem confusão. + + + + A linha volume descreve um volume. O único atributo obrigatório é o nome, neste caso myvol. + + + + A linha plex define um plex. O único parâmetro requerido é a organização, neste caso concat. Nenhum nome é necessário, pois o sistema gera automaticamente um nome a partir do nome do volume, adicionando o sufixo .px, onde x é o número de o plex no volume. Assim, este plex será chamado myvol.p0. + + + + A linha sd descreve um subdisco. As especificações mínimas são o nome de uma unidade na qual irá armazená-lo e o tamanho do subdisco. Nenhum nome é necessário porque o sistema atribui automaticamente nomes derivados do nome do plex adicionando o sufixo .sx, onde x é o número do subdisco no plex. Assim, vinum dá ao subdisco o nome myvol.p0.s0. + + + + Depois de processar este arquivo, o gvinum8 produz a seguinte saída: + + +# gvinum -> create config1 +Configuration summary +Drives: 1 (4 configured) +Volumes: 1 (4 configured) +Plexes: 1 (8 configured) +Subdisks: 1 (16 configured) + + D a State: up Device /dev/da3h Avail: 2061/2573 MB (80%) + + V myvol State: up Plexes: 1 Size: 512 MB + + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB + + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB + + Esta saída mostra o formato de listagem breve de gvinum8. Ele está representado graficamente em . + + +
      + Um volume <filename>vinum</filename> simples + + + + + + +
      + + Esta figura, e as que se seguem, representam um volume, que contém os plexes, que por sua vez contém os subdiscos. Neste exemplo, o volume contém um plex e o plex contém um subdisco. + + Este volume específico não tem nenhuma vantagem específica sobre uma partição de disco convencional. Ele contém um único plex, por isso não é redundante. O plex contém um único subdisco, portanto, não há diferença na alocação de armazenamento de uma partição de disco convencional. As seções a seguir ilustram vários métodos de configuração mais interessantes. +       + + + Maior Resiliência: Espelhamento + + A resiliência de um volume pode ser aumentada pelo espelhamento. Ao dispor um volume espelhado, é importante garantir que os subdiscos de cada plex estejam em unidades diferentes, de modo que uma falha no dispositivo não derrubará os dois plexes. A configuração a seguir espelha um volume: + + drive b device /dev/da4h + volume mirror + plex org concat + sd length 512m drive a + plex org concat + sd length 512m drive b + + Neste exemplo, não foi necessário especificar uma definição de drive a novamente, já que o vinum registra todos os objetos em seu banco de dados de configuração. Depois de processar esta definição, a configuração se parece com: + + + Drives: 2 (4 configured) + Volumes: 2 (4 configured) + Plexes: 3 (8 configured) + Subdisks: 3 (16 configured) + + D a State: up Device /dev/da3h Avail: 1549/2573 MB (60%) + D b State: up Device /dev/da4h Avail: 2061/2573 MB (80%) + + V myvol State: up Plexes: 1 Size: 512 MB + V mirror State: up Plexes: 2 Size: 512 MB + + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB + + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB + + mostra a estrutura graficamente. + + +
      + Um volume <filename>vinum</filename> espelhado + + + + + + +
      + + Neste exemplo, cada plex contém os 512 MB completos do espaço de endereço. Como no exemplo anterior, cada plex contém apenas um único subdisco. +       + + + Otimizando o desempenho + + O volume espelhado no exemplo anterior é mais resistente a falhas do que um volume não espelhado, mas seu desempenho é menor, pois cada gravação no volume requer uma gravação nas duas unidades, utilizando uma grande parte da largura de banda total do disco. As considerações de desempenho exigem uma abordagem diferente: em vez de espelhar, os dados são distribuídos em quantas unidades de disco forem possíveis. A configuração a seguir mostra um volume com um plex distribuído em quatro unidades de disco: + + drive c device /dev/da5h + drive d device /dev/da6h + volume stripe + plex org striped 512k + sd length 128m drive a + sd length 128m drive b + sd length 128m drive c + sd length 128m drive d + + Como antes, não é necessário definir as unidades que já são conhecidas por vinum. Depois de processar esta definição, a configuração se parece com: + + + Drives: 4 (4 configured) + Volumes: 3 (4 configured) + Plexes: 4 (8 configured) + Subdisks: 7 (16 configured) + + D a State: up Device /dev/da3h Avail: 1421/2573 MB (55%) + D b State: up Device /dev/da4h Avail: 1933/2573 MB (75%) + D c State: up Device /dev/da5h Avail: 2445/2573 MB (95%) + D d State: up Device /dev/da6h Avail: 2445/2573 MB (95%) + + V myvol State: up Plexes: 1 Size: 512 MB + V mirror State: up Plexes: 2 Size: 512 MB + V striped State: up Plexes: 1 Size: 512 MB + + P myvol.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p0 C State: up Subdisks: 1 Size: 512 MB + P mirror.p1 C State: initializing Subdisks: 1 Size: 512 MB + P striped.p1 State: up Subdisks: 1 Size: 512 MB + + S myvol.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p0.s0 State: up PO: 0 B Size: 512 MB + S mirror.p1.s0 State: empty PO: 0 B Size: 512 MB + S striped.p0.s0 State: up PO: 0 B Size: 128 MB + S striped.p0.s1 State: up PO: 512 kB Size: 128 MB + S striped.p0.s2 State: up PO: 1024 kB Size: 128 MB + S striped.p0.s3 State: up PO: 1536 kB Size: 128 MB + + +
      + Um volume <filename>vinum</filename> concatenado + + + + + + +
      + + Este volume é representado em . A escuridão das strips indica a posição dentro do espaço de endereço plex, onde as faixas mais claras vêm primeiro e as mais escuras por último. +       + + + Resiliência e Desempenho + + Com hardware suficiente, é possível construir volumes que mostrem maior resiliência e melhor desempenho em comparação com as partições padrão UNIX. Um arquivo de configuração típico pode ser: + + volume raid10 + plex org striped 512k + sd length 102480k drive a + sd length 102480k drive b + sd length 102480k drive c + sd length 102480k drive d + sd length 102480k drive e + plex org striped 512k + sd length 102480k drive c + sd length 102480k drive d + sd length 102480k drive e + sd length 102480k drive a + sd length 102480k drive b + + Os subdiscos do segundo plex são compensados por duas unidades daquelas do primeiro plex. Isso ajuda a garantir que as gravações não vão para os mesmos subdiscos, mesmo que uma transferência passe por duas unidades. + + representa a estrutura deste volume. + + +
      + Um volume <filename>vinum</filename> espelhado e concatenado + + + + + + +
      +       +       + + + Nomeação de Objetos + + O vinum atribui nomes padrões a plexes e subdiscos, embora eles possam ser substituídos. Substituir os nomes padrões não é recomendado, pois não isso traz nenhuma vantagem significativa e pode causar confusão. + + Os nomes podem conter qualquer caractere não-branco, mas é recomendado restringi-los a letras, dígitos e caracteres de sublinhado. Os nomes de volumes, plexes e subdiscos podem ter até 64 caracteres e os nomes das unidades podem ter até 32 caracteres. + + Os objetos vinum são designados a device nodes na hierarquia /dev/gvinum. A configuração mostrada acima faria com que o vinum criasse os seguintes device nodes: + + + + Entradas de dispositivos para cada volume. Estes são os principais dispositivos usados pelo vinum. A configuração acima incluiria os dispositivos /dev/gvinum/myvol, /dev/gvinum/mirror, /dev/gvinum/striped, /dev/gvinum/raid5 e o /dev/gvinum/raid10. + + + + Todos os volumes recebem entradas diretas em /dev/gvinum/. + + + + Os diretórios /dev/gvinum/plex, e /dev/gvinum/sd são aqueles que contém device nodes para cada plex e para cada subdisco, respectivamente. + + + + Por exemplo, considere o seguinte arquivo de configuração: + + drive drive1 device /dev/sd1h + drive drive2 device /dev/sd2h + drive drive3 device /dev/sd3h + drive drive4 device /dev/sd4h + volume s64 setupstate + plex org striped 64k + sd length 100m drive drive1 + sd length 100m drive drive2 + sd length 100m drive drive3 + sd length 100m drive drive4 + + Depois de processar este arquivo, o gvinum8 cria a seguinte estrutura em /dev/gvinum: + + drwxr-xr-x 2 root wheel 512 Apr 13 +16:46 plex + crwxr-xr-- 1 root wheel 91, 2 Apr 13 16:46 s64 + drwxr-xr-x 2 root wheel 512 Apr 13 16:46 sd + + /dev/vinum/plex: + total 0 + crwxr-xr-- 1 root wheel 25, 0x10000002 Apr 13 16:46 s64.p0 + + /dev/vinum/sd: + total 0 + crwxr-xr-- 1 root wheel 91, 0x20000002 Apr 13 16:46 s64.p0.s0 + crwxr-xr-- 1 root wheel 91, 0x20100002 Apr 13 16:46 s64.p0.s1 + crwxr-xr-- 1 root wheel 91, 0x20200002 Apr 13 16:46 s64.p0.s2 + crwxr-xr-- 1 root wheel 91, 0x20300002 Apr 13 16:46 s64.p0.s3 + + Embora seja recomendado que os plexes e subdiscos não sejam atribuídos a nomes específicos, as unidades vinum devem ser nomeadas. Isso possibilita mover uma unidade para um local diferente e ainda reconhecê-la automaticamente. Os nomes dos drives podem ter até 32 caracteres. + + + Criando sistemas de arquivos + + Para o sistema os volumes são idênticos aos discos, com uma exceção. Ao contrário das unidades UNIX, o vinum não particiona os volumes, e, portanto, não contêm uma tabela de partições. Isso exigiu modificação em alguns dos utilitários de disco, notavelmente no newfs8, para que ele não tente interpretar a última letra de um nome do volume vinum como um identificador de partição. Por exemplo, uma unidade de disco pode ter um nome como /dev/ad0a ou /dev/da2h. Esses nomes representam a primeira partição (a) no primeiro (0) disco IDE (ad) e a oitava partição (h) no terceiro (2) disco SCSI (da) respectivamente. Por outro lado, um v olume vinum pode ser chamado de /dev/gvinum/concat, que não tem relação com o nome da partição. + + Para criar um sistema de arquivos neste volume, use newfs8: + + # newfs /dev/gvinum/concat + + + + + Configurando o <filename>vinum</filename> + + O kernel GENERIC não suporta o vinum. É possível compilar um kernel customizado que inclua o suporte estático ao vinum, mas isso não é recomendado. A maneira padrão de iniciar o vinum é como um módulo do kernel. O uso do kldload8 não é necessário porque quando o gvinum8 é iniciado, ele verifica se o módulo já foi carregado e, se ele não tiver sido, ele será carregado automaticamente. + + + + Começando + + O vinum armazena as informações de configuração nos slices dos discos essencialmente da mesma forma que nos arquivos de configuração. Ao ler a partir do banco de dados de configuração, o vinum reconhece um número de palavras-chave que não são permitidas nos arquivos de configuração. Por exemplo, uma configuração de disco pode conter o seguinte texto: + + volume myvol state up +volume bigraid state down +plex name myvol.p0 state up org concat vol myvol +plex name myvol.p1 state up org concat vol myvol +plex name myvol.p2 state init org striped 512b vol myvol +plex name bigraid.p0 state initializing org raid5 512b vol bigraid +sd name myvol.p0.s0 drive a plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 0b +sd name myvol.p0.s1 drive b plex myvol.p0 state up len 1048576b driveoffset 265b plexoffset 1048576b +sd name myvol.p1.s0 drive c plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 0b +sd name myvol.p1.s1 drive d plex myvol.p1 state up len 1048576b driveoffset 265b plexoffset 1048576b +sd name myvol.p2.s0 drive a plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 0b +sd name myvol.p2.s1 drive b plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 524288b +sd name myvol.p2.s2 drive c plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1048576b +sd name myvol.p2.s3 drive d plex myvol.p2 state init len 524288b driveoffset 1048841b plexoffset 1572864b +sd name bigraid.p0.s0 drive a plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 0b +sd name bigraid.p0.s1 drive b plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 4194304b +sd name bigraid.p0.s2 drive c plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 8388608b +sd name bigraid.p0.s3 drive d plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 12582912b +sd name bigraid.p0.s4 drive e plex bigraid.p0 state initializing len 4194304b driveoff set 1573129b plexoffset 16777216b + + As diferenças óbvias aqui são a presença de informações explícitas de localização e nomeação, as quais são ambas permitidas mas desencorajadas, e as informações sobre os estados. O vinum não armazena informações sobre unidades nas informações de configuração. Ele encontra as unidades varrendo as unidades de disco configuradas em busca de partições com um rótulo vinum. Isso permite que o vinum identifique as unidades corretamente, mesmo que elas tenham recebido diferentes IDs de unidade UNIX. + + + Inicialização automática + + O Gvinum apresenta sempre uma inicialização automática assim que o módulo do kernel é carregado, através do loader.conf5. Para carregar o módulo Gvinum no momento da inicialização, adicione geom_vinum_load="YES" ao arquivo /boot/loader.conf. + + Quando o vinum é iniciado com gvinum start, o vinum lê o banco de dados de configuração de uma das unidades vinum. Em circunstâncias normais, cada unidade contém uma cópia idêntica do banco de dados de configuração, portanto, não importa qual unidade é lida. Após uma falha, no entanto, o vinum deve determinar qual unidade foi atualizada mais recentemente e ler a configuração desta unidade. Em seguida, atualiza a configuração, se necessário, de unidades progressivamente a partir das mais antigas. + + + + + + Usando o <filename>vinum</filename> para o sistema de arquivos raiz + + Para uma máquina que tenha sistemas de arquivos totalmente espelhados usando vinum, é desejável também espelhar o sistema de arquivos raiz. Efetuar esta configuração é menos trivial do que espelhar um sistema de arquivos arbitrário porque: + + + + O sistema de arquivos raiz deve estar disponível muito cedo durante o processo de inicialização, portanto a infraestrutura vinum já deve estar disponível no momento. + + + O volume que contém o sistema de arquivos raiz também contém a auto-inicialização do sistema e o kernel. Eles devem ser lidos usando os utilitários nativos do sistema, como o BIOS, que muitas vezes não pode ser instruído sobre os detalhes do vinum. + + + + Nas seções a seguir, o termo volume raiz é geralmente usado para descrever o volume vinum que contém o sistema de arquivos raiz (/). + + + Iniciando o <filename>vinum</filename> cedo o suficiente para o sistema de arquivos raiz + + O vinum deve estar disponível no início da inicialização do sistema pois o loader 8 deve ser capaz de carregar o módulo do kernel vinum antes de iniciar o kernel. Isto pode ser feito colocando esta linha no /boot/loader.conf: + + geom_vinum_load="YES" + + + + + Tornando um volume raiz baseado em <filename>vinum</filename> acessível ao Bootstrap + + O bootstrap atual do FreeBSD tem apenas 7.5 KB de código e não entende as estruturas internas do vinum. Isso significa que não é possível analisar os dados de configuração vinum ou descobrir os elementos de um volume de inicialização. Assim, algumas soluções alternativas são necessárias para fornecer ao código de inicialização a ilusão de que ele está trabalhando com uma partição padrão a que contém o sistema de arquivos raiz. + + Para que isso seja possível, os seguintes requisitos devem ser atendidos para o volume raiz: + + + + O volume raiz não pode ser uma stripe ou RAID -5. + + + + O volume raiz não deve conter mais de um subdisco concatenado por plex. + + + + Observe que é desejável e possível usar vários plexes, cada um contendo uma réplica do sistema de arquivos raiz. O processo de bootstrap usará apenas uma réplica para localizar o bootstrap e todos os arquivos de inicialização, até que o kernel monte o sistema de arquivos raiz. Cada subdisco dentro desses plexes precisa da sua própria ilusão de partição a, para que o respectivo dispositivo seja inicializável. Não é estritamente necessário que cada uma dessas falsas partições a estejam localizadas no mesmo deslocamento dentro de seu dispositivo, em comparação com outros dispositivos contendo plexes do volume raiz. No entanto, é provavelmente uma boa ideia criar os volumes vinum dessa forma para que os dispositivos espelhados resultantes sejam simétricos, para evitar confusão. + + Para configurar essas partições a para cada dispositivo contendo parte do volume raiz, é necessário o seguinte: + + + + A localização, offset desde o início do dispositivo, e o tamanho do subdisco desse dispositivo que faz parte do volume raiz precisam ser examinados, usando o comando: + + # gvinum l -rv root + + Os offsets (deslocamentos) e tamanhos do vinum são medidos em bytes. Eles devem ser divididos por 512 para obter os números de blocos que serão usados pelo bsdlabel. + + + + Execute este comando para cada dispositivo que participa do volume raiz: + + # bsdlabel -e devname + + No comando acima devname deve ser o nome do disco, como da0 para discos sem uma tabela de slices, ou o nome da slice, como ad0s1. + + Se já existir uma partição a no dispositivo a partir de um sistema de arquivos raiz pré-vinum, ela deve ser renomeada para outra coisa para que permaneça acessível (apenas nesse caso), mas ela não será mais usada por padrão para inicializar o sistema. Um sistema de arquivos raiz atualmente montado não pode ser renomeado, portanto, de forma que o processo ser executado quando o sistema for inicializado a partir de uma mídia Fixit ou em um processo de duas etapas em que, em um espelho, o disco que ainda não foi inicializado é manipulado primeiro. + + O offset da partição vinum neste dispositivo (se houver) deve ser adicionado ao deslocamento do respectivo subdisco de volume raiz neste dispositivo. O valor resultante se tornará o valor do offset para a nova partição a. O valor do size para esta partição também pode ser obtido a partir do cálculo acima. O fstype deve ser 4.2BSD. Os valores de fsize, bsize e cpg devem ser escolhidos para corresponder ao sistema de arquivos atual, embora eles sejam relativamente sem importância dentro deste contexto. + + Desta forma, uma nova partição a será estabelecida sobrepondo a partição vinum neste dispositivo. O bsdlabel só permitirá essa sobreposição se a partição vinum tiver sido marcada corretamente usando o modo fstype do vinum. + + + + Temos agora uma falsa partição a em cada dispositivo que possui uma réplica do volume raiz. É altamente recomendável verificar o resultado usando um comando como: + + # fsck -n /dev/devnamea + + + + Deve ser lembrado que todos os arquivos contendo informações de controle devem ser relativos ao sistema de arquivos raiz no volume vinum e que, ao configurarmos um novo volume raiz vinum, ele pode não corresponder o sistema de arquivos raiz que está atualmente ativo. Então, em particular, o /etc/fstab e /boot/loader.conf precisam ser ajustados. + + Na próxima reinicialização, o bootstrap deve descobrir as informações de controle apropriadas do novo sistema de arquivos raiz baseado no vinum e agir de acordo. No final do processo de inicialização do kernel, após todos os dispositivos terem sido anunciados, o aviso de destaque que mostra o sucesso desta configuração é uma mensagem como: + + Mounting root from ufs:/dev/gvinum/root + + + + Exemplo de uma configuração raiz baseada em <filename>vinum</filename> + + Depois que o volume raiz vinum foi configurado, a saída de gvinum l -rv root pode parecer com: + + ... +Subdisk root.p0.s0: + Size: 125829120 bytes (120 MB) + State: up + Plex root.p0 at offset 0 (0 B) + Drive disk0 (/dev/da0h) at offset 135680 (132 kB) + +Subdisk root.p1.s0: + Size: 125829120 bytes (120 MB) + State: up + Plex root.p1 at offset 0 (0 B) + Drive disk1 (/dev/da1h) at offset 135680 (132 kB) + + Os valores a serem observados são 135680 para o offset, relativo à partição /dev/da0h. Isso se traduz em 265 blocos de discos de 512 bytes nos termos do bsdlabel. Da mesma forma, o tamanho desse volume raiz é de 245760 blocos de 512 bytes. O /dev/da1h, contém a segunda réplica deste volume raiz, e possui uma configuração simétrica. + + O bsdlabel para esses dispositivos pode se parecer com: + + ... +8 partitions: +# size offset fstype [fsize bsize bps/cpg] + a: 245760 281 4.2BSD 2048 16384 0 # (Cyl. 0*- 15*) + c: 71771688 0 unused 0 0 # (Cyl. 0 - 4467*) + h: 71771672 16 vinum # (Cyl. 0*- 4467*) + + Pode-se observar que o parâmetro size para a falsa partição a corresponde ao valor descrito acima, enquanto o parâmetro offset é a soma do deslocamento dentro da partição vinum h, e o offset desta partição dentro do dispositivo ou slice. Esta é uma configuração típica que é necessária para evitar o problema descrito em . A partição a inteira está completamente dentro da partição h que contém todos os dados vinum para este dispositivo. + + No exemplo acima, todo o dispositivo é dedicado ao vinum e não há sobra de partição raiz pré-vinum. + + + + Soluções de problemas + + A lista a seguir contém algumas armadilhas e soluções conhecidas. + + + Sistema de bootstrap carrega, mas o sistema não + + Se por algum motivo o sistema não continuar a inicialização, o bootstrap pode ser interrompido pressionando espaço no aviso de 10 segundos. A variável vinum.autostart do loader pode ser examinada digitando show e manipulada usando set ou unset. + + Se o módulo do kernel vinum ainda não estava na lista de módulos para carregar automaticamente, digite load geom_vinum. + + Quando estiver pronto, o processo de inicialização pode ser continuado digitando-se boot -as, no qual solicita ao kernel que peça ao sistema de arquivos raiz para montar () e fazer com que o processo de inicialização pare no modo single user(), em que o sistema de arquivos raiz é montado como somente leitura. Dessa forma, mesmo que apenas um plex de um volume multi-plex tenha sido montado, não estaremos arriscando nenhuma inconsistência de dados entre os plexes. + + No prompt solicitando que um sistema de arquivos raiz seja montado, qualquer dispositivo que contenha um sistema de arquivos raiz válido pode ser inserido. Se o /etc/fstab estiver configurado corretamente, o padrão deve ser algo como ufs:/dev/gvinum/root. Uma opção alternativa típica seria algo como ufs:da0d, que poderia ser uma partição hipotética contendo o sistema de arquivos raiz pré-vinum. Deve-se tomar cuidado se uma das partições alias a for inserida aqui, para verificar se ela realmente faz referência aos subdiscos do dispositivo raiz vinum, porque em uma configuração espelhada, isso apenas montaria uma parte de um dispositivo raiz espelhado. Se este sistema de arquivos tiver que ser montado no modo read-write mais tarde, será necessário remover o(s) outro(s) plex(es) do volume raiz vinum, já que esses plexes car regariam dados inconsistentes. + + + + Apenas o bootstrap primário carrega + + Se o /boot/loader falhar ao carregar, mas o bootstrap primário ainda carregar (visível por um único traço na coluna esquerda da tela logo após o processo de boot ser iniciado), uma tentativa pode ser feita para interromper o bootstrap primário pressionando espaço. Isso fará com que o bootstrap pare no estágio dois. Uma tentativa pode ser feita aqui para inicializar uma partição alternativa, como a partição que contém o sistema de arquivos raiz anterior que foi movido de a. + + + + Nada carrega e o Bootstrap entra em panic + + Esta situação acontecerá se o bootstrap tiver sido destruído pela instalação do vinum. Infelizmente, o vinum acidentalmente deixa apenas 4 KB no início de sua partição livre antes de começar a escrever suas informações de cabeçalho vinum. No entanto, o estágio um e dois bootstraps mais o bsdlabel exigem 8 KB. Portanto, se uma partição vinum tiver sido iniciada no offset 0 dentro de uma slice ou disco que deveria ser inicializável, a configuração do vinum irá estragar o bootstrap. + + Da mesma forma, se a situação acima foi recuperada, inicializando de uma mídia Fixit, e o bootstrap foi reinstalado usando bsdlabel -B como descrito em , o bootstrap irá estragar o cabeçalho vinum e o vinum não encontrará mais seu(s) disco(s). Entretando nenhum dado de configuração real do vinum e nenhum volume vinum de dados foi descartado, sendo possível recuperá-los digitando de novo exatamente as mesmas configurações do vinum, a situação é difícil de corrigir de forma definitiva. Pois será necessário mover toda a partição vinum em pelo menos 4 KB, para que o cabeçalho vinum e o bootstrap do sistema não colidam mais. + + + +
      Added: head/pt_BR.ISO8859-1/articles/vinum/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/vinum/pt_BR.po Sat Sep 15 14:15:22 2018 (r52259) @@ -0,0 +1,2362 @@ +# $FreeBSD$ +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Lucas Andrade , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-15 14:09+0000\n" +"PO-Revision-Date: 2018-09-15 01:45+0000\n" +"Last-Translator: Lucas Andrade \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018\n" +"Lucas Andrade, slucasandrade@protonmail.ch, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:16 +msgid "The vinum Volume Manager" +msgstr "O Gerenciador de Volume vinum" + +#. (itstool) path: authorgroup/author +#: article.translate.xml:19 +msgid "" +" Greg Lehey Originally written by " +msgstr "" +" Greg Lehey Escrito originalmente por " + +#. (itstool) path: sect1/title +#: article.translate.xml:30 +msgid "Synopsis" +msgstr "Sinopse" + +#. (itstool) path: sect1/para +#: article.translate.xml:32 +msgid "" +"No matter the type of disks, there are always potential problems. The disks " +"can be too small, too slow, or too unreliable to meet the system's " +"requirements. While disks are getting bigger, so are data storage " +"requirements. Often a file system is needed that is bigger than a disk's " +"capacity. Various solutions to these problems have been proposed and " +"implemented." +msgstr "" +"Não importa o tipo de disco, sempre há problemas em potencial. Os discos " +"podem ser muito pequenos, muito lentos ou pouco confiáveis para atender aos " +"requisitos do sistema. Enquanto os discos estão ficando maiores, também " +"ficam maiores os requisitos para armazenamento de dados. Geralmente, é " +"necessário um sistema de arquivos maior que a capacidade de um disco. Várias " +"soluções para esses problemas foram propostas e implementadas." + +#. (itstool) path: sect1/para +#: article.translate.xml:40 +msgid "" +"One method is through the use of multiple, and sometimes redundant, disks. " +"In addition to supporting various cards and controllers for hardware " +"Redundant Array of Independent Disks RAID systems, the " +"base FreeBSD system includes the vinum volume manager, " +"a block device driver that implements virtual disk drives and addresses " +"these three problems. vinum provides more flexibility, " +"performance, and reliability than traditional disk storage and implements " +"RAID-0, RAID-1, and RAID-5 models, both individually and in combination." +msgstr "" +"Um método é através do uso de vários discos, e às vezes discos redundantes. " +"Além de suportar várias placas e controladoras para sistemas RAID (Redundant Array of Independent Disks), o sistema básico do FreeBSD " +"inclui o gerenciador de volumes vinum, um driver de " +"dispositivo de bloco que implementa discos virtuais e aborda esses três " +"problemas. O vinum oferece mais flexibilidade, " +"desempenho e confiabilidade do que o armazenamento em disco tradicional e " +"implementa os modelos RAID-0, RAID-1 e " +" RAID-5, tanto individualmente quanto combinados." + +#. (itstool) path: sect1/para +#: article.translate.xml:53 +msgid "" +"This chapter provides an overview of potential problems with traditional " +"disk storage, and an introduction to the vinum volume " +"manager." +msgstr "" +"Este capítulo fornece uma visão geral dos possíveis problemas com o " +"armazenamento em disco tradicional e uma introdução ao gerenciador de " +"volumes vinum." + +#. (itstool) path: note/para +#: article.translate.xml:58 +msgid "" +"Starting with FreeBSD 5, vinum has been rewritten in " +"order to fit into the GEOM architecture, while " +"retaining the original ideas, terminology, and on-disk metadata. This " +"rewrite is called gvinum (for GEOM vinum). While this chapter uses the term vinum, any " +"command invocations should be performed with gvinum. The " +"name of the kernel module has changed from the original vinum.ko to geom_vinum.ko, and all device nodes reside " +"under /dev/gvinum instead of " +"/dev/vinum. As of FreeBSD 6, the " +"original vinum implementation is no longer available in " +"the code base." +msgstr "" +"Começando com o FreeBSD 5, o vinum foi reescrito para " +"se encaixar na Arquitetura GEOM, mantendo as idéias " +"originais, a terminologia e os metadados no disco. Esta reescrita é chamada " +"gvinum (para GEOM vinum). Enquanto " +"este capítulo usa o termo vinum, qualquer invocação de " +"comandos deve ser executada com o gvinum. O nome do " +"módulo do kernel mudou do original vinum.ko para " +"geom_vinum.ko, e todos os device nodes residem em " +"/dev/gvinum em vez de /dev/vinum. A partir do FreeBSD 6, a " +"implementação original do vinum não está mais " +"disponível no código base." + +#. (itstool) path: sect1/title +#: article.translate.xml:76 +msgid "Access Bottlenecks" +msgstr "Gargalos de Acesso" + +#. (itstool) path: sect1/para +#: article.translate.xml:78 +msgid "" +"Modern systems frequently need to access data in a highly concurrent manner. " +"For example, large FTP or HTTP servers can maintain thousands of concurrent " +"sessions and have multiple 100 Mbit/s connections to the outside world, well " +"beyond the sustained transfer rate of most disks." +msgstr "" +"Sistemas modernos frequentemente precisam acessar dados de uma maneira " +"altamente concorrente. Por exemplo, grandes servidores FTP ou HTTP podem " +"manter milhares de sessões simultâneas e ter múltiplas conexões de 100 Mbit/" +"s para o mundo externo, muito além da taxa de transferência sustentada da " +"maioria dos discos." + +#. (itstool) path: sect1/para +#: article.translate.xml:84 +msgid "" +"Current disk drives can transfer data sequentially at up to 70 MB/s, but " +"this value is of little importance in an environment where many independent " +"processes access a drive, and where they may achieve only a fraction of " +"these values. In such cases, it is more interesting to view the problem from " +"the viewpoint of the disk subsystem. The important parameter is the load " +"that a transfer places on the subsystem, or the time for which a transfer " +"occupies the drives involved in the transfer." +msgstr "" +"As unidades de disco atuais podem transferir dados sequencialmente a até 70 " +"MB/s, mas esse valor é de pouca importância em um ambiente em que muitos " +"processos independentes acessam uma unidade e onde podem obter apenas uma " +"fração desses valores. Nesses casos, é mais interessante visualizar o " +"problema do ponto de vista do subsistema de disco. O parâmetro importante é " +"a carga que uma transferência coloca no subsistema ou o tempo pelo qual uma " +"transferência ocupa as unidades envolvidas na transferência." + +#. (itstool) path: sect1/para +#: article.translate.xml:94 +msgid "" +"In any disk transfer, the drive must first position the heads, wait for the " +"first sector to pass under the read head, and then perform the transfer. " +"These actions can be considered to be atomic as it does not make any sense " +"to interrupt them." +msgstr "" +"Em qualquer transferência de disco, a unidade deve primeiro posicionar as " +"cabeças, aguardar que o primeiro setor passe sob a cabeça de leitura e " +"depois realizar a transferência. Essas ações podem ser consideradas " +"atômicas, pois não faz sentido interrompê-las." + +#. (itstool) path: sect1/para +#: article.translate.xml:100 +msgid "" +" Consider a typical transfer of about " +"10 kB: the current generation of high-performance disks can position the " +"heads in an average of 3.5 ms. The fastest drives spin at 15,000 rpm, so the " +"average rotational latency (half a revolution) is 2 ms. At 70 MB/s, the " +"transfer itself takes about 150 μs, almost nothing compared to the " +"positioning time. In such a case, the effective transfer rate drops to a " +"little over 1 MB/s and is clearly highly dependent on the transfer size." +msgstr "" +" Considere uma transferência típica de " +"cerca de 10 kB: a geração atual de discos de alto desempenho pode posicionar " +"as cabeças em uma média de 3,5 ms. As unidades mais rápidas giram a 15.000 " +"rpm, portanto a latência rotacional média (meia revolução) é de 2 ms. A 70 " +"MB/s, a própria transferência leva cerca de 150 μs, quase nada em comparação " +"com o tempo de posicionamento. Nesse caso, a taxa de transferência efetiva " +"cai para pouco mais de 1 MB/s e é claramente altamente dependente do tamanho " +"da transferência." + +#. (itstool) path: sect1/para +#: article.translate.xml:111 +msgid "" +"The traditional and obvious solution to this bottleneck is more " +"spindles: rather than using one large disk, use several smaller " +"disks with the same aggregate storage space. Each disk is capable of " +"positioning and transferring independently, so the effective throughput " +"increases by a factor close to the number of disks used." +msgstr "" +"A solução tradicional e óbvia para esse gargalo é mais eixos: " +"em vez de usar um disco grande, use vários discos menores com o mesmo espaço " +"de armazenamento agregado. Cada disco é capaz de se posicionar e transferir " +"de forma independente, portanto, o rendimento efetivo aumenta em um fator " +"próximo ao número de discos usados." + +#. (itstool) path: sect1/para +#: article.translate.xml:118 +msgid "" +"The actual throughput improvement is smaller than the number of disks " +"involved. Although each drive is capable of transferring in parallel, there " +"is no way to ensure that the requests are evenly distributed across the " +"drives. Inevitably the load on one drive will be higher than on another." +msgstr "" +"A melhoria real da taxa de transferência é menor que o número de discos " +"envolvidos. Embora cada unidade seja capaz de transferir em paralelo, não há " +"como garantir que as solicitações sejam distribuídas uniformemente pelas " +"unidades. Inevitavelmente, a carga em uma unidade será maior que em outra." + +#. (itstool) path: sect1/indexterm +#: article.translate.xml:124 +msgid "disk concatenation" +msgstr "Concatenação de disco" + +#. (itstool) path: sect1/indexterm +#: article.translate.xml:127 +msgid "Vinum concatenation" +msgstr "Concatenação Vinum" + +#. (itstool) path: sect1/para +#: article.translate.xml:132 +msgid "" +"The evenness of the load on the disks is strongly dependent on the way the " +"data is shared across the drives. In the following discussion, it is " +"convenient to think of the disk storage as a large number of data sectors " +"which are addressable by number, rather like the pages in a book. The most " +"obvious method is to divide the virtual disk into groups of consecutive " +"sectors the size of the individual physical disks and store them in this " +"manner, rather like taking a large book and tearing it into smaller " +"sections. This method is called concatenation and has " +"the advantage that the disks are not required to have any specific size " +"relationships. It works well when the access to the virtual disk is spread " +"evenly about its address space. When access is concentrated on a smaller " +"area, the improvement is less marked. " +"illustrates the sequence in which storage units are allocated in a " +"concatenated organization." +msgstr "" +"A uniformidade da carga nos discos é fortemente dependente da maneira como " +"os dados são compartilhados entre as unidades. Na discussão a seguir, é " +"conveniente pensar no armazenamento em disco como um grande número de " +"setores de dados que são endereçáveis por número, mais ou menos como as " +"páginas de um livro. O método mais óbvio é dividir o disco virtual em grupos " +"de setores consecutivos do tamanho dos discos físicos individuais e armazená-" +"los dessa maneira, mais ou menos como pegar um livro grande e dividi-lo em " +"seções menores. Esse método é chamado de concatenação e " *** DIFF OUTPUT TRUNCATED AT 1000 LINES *** From owner-svn-doc-all@freebsd.org Sat Sep 15 17:33:42 2018 Return-Path: Delivered-To: svn-doc-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F1AD710AAF63; Sat, 15 Sep 2018 17:33:41 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D53392949; Sat, 15 Sep 2018 17:33:41 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 9764A168A6; Sat, 15 Sep 2018 17:33:41 +0000 (UTC) (envelope-from ebrandi@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id w8FHXfBm029665; Sat, 15 Sep 2018 17:33:41 GMT (envelope-from ebrandi@FreeBSD.org) Received: (from ebrandi@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id w8FHXeGN029661; Sat, 15 Sep 2018 17:33:40 GMT (envelope-from ebrandi@FreeBSD.org) Message-Id: <201809151733.w8FHXeGN029661@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: ebrandi set sender to ebrandi@FreeBSD.org using -f From: Edson Brandi Date: Sat, 15 Sep 2018 17:33:40 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r52260 - in head/pt_BR.ISO8859-1/articles: . bsdl-gpl X-SVN-Group: doc-head X-SVN-Commit-Author: ebrandi X-SVN-Commit-Paths: in head/pt_BR.ISO8859-1/articles: . bsdl-gpl X-SVN-Commit-Revision: 52260 X-SVN-Commit-Repository: doc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Sep 2018 17:33:42 -0000 Author: ebrandi Date: Sat Sep 15 17:33:40 2018 New Revision: 52260 URL: https://svnweb.freebsd.org/changeset/doc/52260 Log: pt_BR.ISO8859-1/articles/bsdl-gpl: New pt_BR translation into .po format * content synchronized with en_US document (rev 43184) * article.xml converted to .po * .po file was translated to pt_BR * .po and .xml file has been set to UTF-8 encoding * information about volunteers who translated and/or revised the document was added to the header of the .po file Approved by: gabor (mentor, implicit) Obtained from: The FreeBSD Brazilian Portuguese Documentation Project Added: head/pt_BR.ISO8859-1/articles/bsdl-gpl/ head/pt_BR.ISO8859-1/articles/bsdl-gpl/Makefile (contents, props changed) head/pt_BR.ISO8859-1/articles/bsdl-gpl/article.xml (contents, props changed) head/pt_BR.ISO8859-1/articles/bsdl-gpl/pt_BR.po (contents, props changed) Modified: head/pt_BR.ISO8859-1/articles/Makefile Modified: head/pt_BR.ISO8859-1/articles/Makefile ============================================================================== --- head/pt_BR.ISO8859-1/articles/Makefile Sat Sep 15 14:15:22 2018 (r52259) +++ head/pt_BR.ISO8859-1/articles/Makefile Sat Sep 15 17:33:40 2018 (r52260) @@ -5,6 +5,7 @@ # $FreeBSD$ SUBDIR = +SUBDIR+= bsdl-gpl SUBDIR+= building-products SUBDIR+= contributing SUBDIR+= cups Added: head/pt_BR.ISO8859-1/articles/bsdl-gpl/Makefile ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/bsdl-gpl/Makefile Sat Sep 15 17:33:40 2018 (r52260) @@ -0,0 +1,24 @@ +# +# The FreeBSD Documentation Project +# The FreeBSD Brazilian Portuguese Documentation Project +# +# $FreeBSD$ +# +# Article: BSD License vs GPL License + +MAINTAINER=ebrandi@FreeBSD.org + +DOC?= article + +FORMATS?= html html-split +WITH_ARTICLE_TOC?= YES + +INSTALL_COMPRESSED?= gz +INSTALL_ONLY_COMPRESSED?= + +SRCS= article.xml + +URL_RELPREFIX?= ../../../.. +DOC_PREFIX?= ${.CURDIR}/../../.. + +.include "${DOC_PREFIX}/share/mk/doc.project.mk" Added: head/pt_BR.ISO8859-1/articles/bsdl-gpl/article.xml ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/bsdl-gpl/article.xml Sat Sep 15 17:33:40 2018 (r52260) @@ -0,0 +1,231 @@ + + +
      + + Por que você deve usar uma licença de estilo BSD em seu Projeto Open Source + + + BruceMontague
      brucem@alumni.cse.ucsc.edu +
      +       + + + FreeBSD is a registered trademark of the FreeBSD Foundation. + Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, and Xeon are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. + Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the ™ or the ® symbol. + + + $FreeBSD$ + + $FreeBSD$ +       + + + Introdução + + Este documento apresenta argumentos para a utilização de uma licença de estilo BSD para software e dados; especificamente recomenda utilizar uma licença de estilo BSD no lugar de uma GPL. Também pode ser lido como uma introdução e resumo das licenças de Projeto Open Source, BSD versus GPL. + + + + Uma Breve História do Open Source + + Muito antes do termo Open Source ser utilizado, o software era desenvolvido por associações livres de programadores e os softwares eram livremente trocados ou negociados. A partir do início dos anos 50, organizações como a SHARE e a DECUS desenvolviam grande parte do software que as empresas de hardware empacotavam em suas ofertas. Naquela época, as empresas de computadores estavam no negócio de hardware; qualquer coisa que reduzisse o custo do software e disponibilizasse mais programas tornava as empresas de hardware mais competitivas. + + Este modelo mudou nos anos 60. Em 1965, a ADR desenvolveu o primeiro produto de software licenciado e independente de uma empresa de hardware. A ADR estava competindo contra um pacote gratuito da IBM que foi originalmente desenvolvido por seus próprios clientes. A ADR patenteou seu software em 1968. Para interromper o compartilhamento de seu programa, eles forneceram seu software sob leasing de equipamento, na qual o pagamento foi distribuído durante a vida útil do produto. A ADR reteve a propriedade e pôde controlar a revenda e a reutilização. + + Em 1969, o Departamento de Justiça dos EUA acusou a IBM de destruir negócios e empresas com seu agrupamento de software livre e hardware IBM. Como resultado deste processo, a IBM separou seu software; isto é, os softwares tornaram-se produtos independentes e separados do hardware. + + Em 1968, a Informatics apresentou o primeiro software comercial revolucionário e rapidamente foi estabelecido o conceito do produto de software, da empresa de software e de taxas de retorno bem altas. A Informatics desenvolveu a licença perpétua que agora é comum em toda a indústria de computadores, onde a propriedade do software nunca é transferida para o cliente. + + + + Unix de uma Perspectiva de Licenciamento BSD + + A AT&T, que detinha a implementação original do Unix, era um monopólio regulado publicamente e amarrado a um tribunal anti-trust; ela foi legalmente impossibilitada de vender um produto no mercado de software. Entretanto, ela podia fornece-lo a instituições acadêmicas pelo preço da mídia. + + As universidades adotaram rapidamente o Unix depois da divulgação de sua disponibilidade em uma conferência de Sistema Operacional. Foi extremamente útil o Unix rodar no PDP-11, um computador de 16 bits muito acessível na época, e que foi codificado em uma linguagem de alto nível, que era comprovadamente boa para a programação de sistemas. O DEC PDP-11 tinha, na verdade, uma interface de hardware aberta, projetada para tornar mais fácil para os clientes escreverem seus próprios sistemas operacionais, o que era comum. O famoso fundador da DEC, Ken Olsen, proclamou que o software vem do céu quando você tem um bom hardware. + + O autor do Unix, Ken Thompson, retornou à Universidade da Califórnia de Berkeley (UCB) em 1975, e lecionou sobre o kernel linha por linha. Isso acabou resultando em um sistema evoluído conhecido como BSD (Berkeley Standard Distribution). A UCB converteu o Unix em 32 bits, adicionou memória virtual e implementou a stack TCP/IP, a qual foi essencialmente necessária para a construção da Internet. A UCB disponibilizou o BSD pelo custo da mídia, e isso ficou conhecido como a licença BSD. Um cliente comprava o Unix da AT&T e depois comprava uma fita BSD da UCB. + + Em meados da década de 80, um processo anti-trust governamental contra a ATT resultou no seu desmembramento. A ATT ainda possuía o Unix e a partir daquele momento podia vendê-lo. Então a ATT embarcou em um esforço agressivo de licenciamento e a maioria dos Unixes comerciais da época tornaram-se derivações do Unix ATT. + + No início dos anos 90, a ATT processou a UCB por violações de licenças relacionadas ao BSD. A UCB descobriu que a ATT havia incorporado, sem reconhecimento ou pagamento, muitas melhorias nos produtos da ATT originadas no BSD, e isso resultou em um longo processo judicial entre a ATT e a UCB. Durante esse período, alguns programadores da UCB embarcaram em um projeto para reescrever todos os códigos ATT que estavam associados ao BSD. Este projeto resultou em um sistema chamado BSD 4.4-lite (lite porque não era um sistema completo; faltavam 6 arquivos-chave ATT). + + Uma longa série de artigos foram publicados um pouco depois disso na revista Dr. Dobbs, que descreviam uma versão do Unix derivada do BSD para PC 386, na qual os 6 arquivos que estavam faltando no 4.4 lite foram substituídos por arquivos de licença BSD. Este sistema, chamado 386BSD, foi devido ao ex programador da UCB, William Jolitz. Ele se tornou a base original de todos os BSD para PCs que estão atualmente em uso. + + Em meados da década de 90, a Novell comprou os direitos do Unix da ATT e um acordo (então secreto) foi fechado para encerrar o processo. A UCB logo encerrou seu suporte para o BSD. + + + + O Estado Atual das Licenças FreeBSD e BSD + + A chamada nova licença BSD aplicada ao FreeBSD nos últimos anos é efetivamente uma afirmação de que você pode fazer qualquer coisa com o programa ou seu código fonte, mas você não tem nenhuma garantia e nenhum dos autores tem qualquer responsabilidade (basicamente, você não pode processar ninguém). Esta nova licença BSD destina-se a incentivar a comercialização de produtos. Qualquer código BSD pode ser vendido ou incluído em produtos proprietários, sem quaisquer restrições quanto à disponibilidade do seu código ou seu comportamento futuro. + + Não confunda a nova licença BSD com domínio público. Enquanto um item no domínio público também é gratuito para todos, ele não possui um proprietário. + + + + + As origens da GPL + + Enquanto o futuro do Unix era tão confuso no final dos anos 80 e início dos anos 90, a GPL, um outro desenvolvimento com importantes considerações sobre licenciamento, surgiu. + + Richard Stallman, o desenvolvedor do Emacs, era membro da equipe do MIT quando seu laboratório mudou de sistemas domésticos para sistemas proprietários. Stallman ficou chateado quando descobriu que não podia adicionar legalmente pequenas melhorias ao sistema. (Muitos dos colegas de trabalho de Stallman tinham saído para formar duas empresas com base em software desenvolvido no MIT e licenciado pelo MIT; parece ter havido desacordo sobre o acesso ao código-fonte desse software). Stallman criou uma alternativa para a licença de software comercial e a chamou de GPL, ou "GNU Public License". Ele também fundou uma fundação sem fins lucrativos, a Free Software Foundation (FSF), que pretendia desenvolver um sistema operacional completo, incluindo todos os softwares associados, e que não estaria sujeito a uma licença proprietária. Este sistema foi chamado de GNU, que significa "GNU is Not Unix". + + A GPL foi projetada para ser o oposto da licença proprietária padrão. Para este fim, quaisquer modificações que eram feitas a um programa GPL tinham que ser devolvidas à comunidade GPL (exigindo que o código fonte do programa fosse disponibilizado para o usuário) e que qualquer programa que utilizar ou linkar com código GPL, teria que estar sob a GPL. A GPL pretendia impedir que o software se tornasse proprietário. Como o último parágrafo da GPL afirma: + + This General Public License does not permit incorporating your program into proprietary programs.[1] + + A GPL é uma licença complexa, então aqui estão algumas regras básicas ao usar a GPL: + + + + você pode cobrar o quanto quiser para distribuir, dar suporte ou documentar o software, mas não pode vender o software em si. + + a regra básica indica que, se um código fonte GPL for necessário para um programa compilar, então o programa deve estar sob a GPL. Linkar estaticamente a uma biblioteca GPL requer que um programa esteja sob a GPL. + + a GPL exige que quaisquer patentes associadas ao software GPL sejam licenciadas para uso livre de todos. + + simplesmente agregar softwares juntos, como quando vários programas são colocados em um disco, não conta como inclusão de programas GPL em programas não-GPL. + + o que se resulta de um programa não conta como um trabalho derivado. Isso permite que o compilador gcc seja utilizado em ambientes comerciais sem problemas legais. + + como o kernel do Linux está sob a GPL, qualquer código estaticamente linkado ao kernel do Linux deve ser GPL. Este requisito pode ser contornado ao linkar dinamicamente módulos carregáveis do kernel. Isso permite que as empresas distribuam drivers binários, mas geralmente tem a desvantagem de que eles só funcionarão para versões específicas do kernel do Linux. + + + Devido em parte à sua complexidade, em muitas partes do mundo hoje as legalidades da GPL estão sendo ignoradas em relação ao Linux e softwares relacionados. As ramificações de longo prazo por causa disso não são claras. + + + + + As origens do Linux e da LGPL + + Enquanto as guerras comerciais do Unix se intensificavam, o kernel do Linux foi desenvolvido como um clone do PC Unix. Linus Torvalds credita a existência do compilador GNU C e das ferramentas GNU associadas pela existência do Linux. Ele colocou o kernel do Linux sob a GPL. + + Lembre-se de que a GPL requer que qualquer software que seja estaticamente linkado a um código GPL, também seja colocado sob a GPL. O código fonte desse software deve ser disponibilizado ao usuário do programa. O link dinâmico, no entanto, não é considerado uma violação da GPL. A pressão para colocar aplicativos proprietários no Linux tornou-se esmagadora. Tais aplicativos geralmente precisavam se linkar a bibliotecas do sistema. Isso resultou em uma versão modificada da GPL chamada LGPL ("Library", e depois renomeado para "Lesser", GPL). A LGPL permite que o código proprietário faça link com à biblioteca GNU C, glibc. Você não precisa liberar o código-fonte para um software que foi linkado dinamicamente a uma biblioteca LGPL. + + Se você linkar estaticamente uma aplicação com a glibc, o que geralmente é necessário em sistemas embarcados, não será possível manter seu aplicativo proprietário, isto é, o código fonte deve ser liberado. Tanto a GPL quanto a LGPL requerem que qualquer software sob suas licenças liberem quaisquer modificações no código fonte. + + + + + Licenças Open Source e o Problema dos Softwares Orfãos + + Um problema sério associado ao software proprietário é conhecido como orphaning. Isso ocorre quando um simples negócio falha ou quando uma mudança na estratégia de um produto faz com que uma cadeia de sistemas e empresas que dependiam deste produto, também falhem por motivos que estão fora de seus controles. Décadas de experiência mostraram que o tamanho ou o sucesso momentâneo de um fornecedor de software não é uma garantia de que seu software permanecerá disponível, pois as condições e estratégias atuais do mercado podem mudar rapidamente. + + A GPL tenta impedir o software órfão cortando o link para a propriedade intelectual proprietária. + + Uma licença BSD concede a uma pequena empresa o equivalente a um software-in-escrow sem quaisquer complicações ou custos legais. Se um programa licenciado pela BSD se torna órfão, uma empresa pode simplesmente assumir, de maneira proprietária, o programa do qual eles são dependentes. Uma situação ainda melhor ocorre quando uma base de código BSD é mantida por um pequeno consórcio informal, uma vez que o processo de desenvolvimento não depende da sobrevivência de uma única empresa ou de uma linha de produtos. A capacidade de sobrevivência da equipe de desenvolvimento quando eles estão mentalmente seguros é muito mais importante do que a simples disponibilidade física do código-fonte. + + + + + O que uma licença não pode fazer + + Nenhuma licença pode garantir disponibilidade futura do software. Embora um detentor de direitos autorais possa tradicionalmente mudar os termos de um direito autoral a qualquer momento, a presunção na comunidade BSD é de que tal tentativa simplesmente faz com que o código fonte seja derivado (fork). + + A GPL proíbe explicitamente a revogação da licença. Ocorreu no entanto, que uma empresa (Mattel) comprou um copyright GPL (cphack), e revogou todo o direito autoral, foi a tribunal e conseguiu prevalecer [2]. Ou seja, eles revogaram legalmente toda a distribuição e todos os trabalhos derivados com base nos direitos autorais. Se isso pode acontecer com uma distribuição maior e mais dispersa, fica uma questão em aberto; Há também alguma confusão sobre se o software estava realmente sob a GPL. + + Em outro exemplo, a Red Hat comprou a Cygnus, uma empresa de engenharia que havia assumido o desenvolvimento das ferramentas de compilação da FSF. A Cygnus foi capaz de fazer isso porque eles desenvolveram um modelo de negócios no qual eles vendiam suporte para o software GNU. Isso permitiu que eles empregassem cerca de 50 engenheiros e os orientassem na direção dos programas, contribuindo com a preponderância de modificações. Como afirma Donald Rosenberg, "projetos usando licenças como a GPL ... vivem sob constante ameaça de que alguém assuma o projeto produzindo uma versão melhor do código e fazendo isso mais rápido que os proprietários originais". [3] + + + + + Vantagens e Desvantagens da GPL + + Um motivo comum para usar a GPL é ao modificar ou criar extensões ao compilador gcc. Isso é particularmente apropriado quando se trabalha com CPUs especiais únicas em ambientes em que todos os custos de software provavelmente são considerados como despesas gerais, com expectativas mínimas de que outros usarão o compilador resultante. + + A GPL também é atraente para pequenas empresas que vendem CDs em um ambiente em que o "buy-low, sell-high" ainda pode dar ao usuário final um produto muito barato. Também é atraente para empresas que esperam sobreviver fornecendo várias formas de suporte técnico, incluindo documentação, para o mundo da propriedade intelectual GPL. + + Um uso menos divulgado e não intencional da GPL é que ela é muito favorável a grandes empresas que querem minar empresas de software. Em outras palavras, a GPL é bem adequada para uso como arma de marketing, reduzindo potencialmente o benefício econômico geral e contribuindo para o comportamento monopolista. + + A GPL pode representar um problema real para aqueles que desejam comercializar e lucrar com software. Por exemplo, a GPL aumenta a dificuldade que um estudante de pós-graduação terá em formar diretamente uma empresa para comercializar seus resultados de pesquisa, ou a dificuldade que um aluno terá em ingressar em uma empresa com a suposição de que um promissor projeto de pesquisa será comercializado. + + Para aqueles que precisam trabalhar com implementações linkadas estaticamente em vários modelos de software, a GPL é geralmente uma licença ruim, porque impede o uso de implementações proprietárias dos modelos. A GPL minimiza, assim, o número de programas que podem ser compilados usando o modelo GPL. A GPL tinha como objetivo não fornecer um mecanismo para desenvolver um padrão na engenharia de produtos proprietários. (Isso não se aplica a aplicativos Linux porque eles não usam links estáticos, em vez disso, usam uma trap-based API.) + + A GPL tenta fazer com que os programadores contribuam para um conjunto de programas em desenvolvimento, para então competir na distribuição e suporte deste conjunto. Essa situação não é realista para muitos dos padrões de sistema exigidos, que podem ser aplicados em ambientes amplamente diferentes, e que exigem personalização comercial ou integração com padrões legados sob licenças existentes (não-GPL). Os sistemas real-time usam frequentemente links estáticos, de modo que a GPL e a LGPL são definitivamente consideradas problemas potenciais por muitas empresas de sistemas embarcados. + + A GPL é uma tentativa de manter os trabalhos disponíveis, independentemente da demanda nos estágios de pesquisa e desenvolvimento. Isso maximiza os benefícios para pesquisadores e desenvolvedores, a um custo desconhecido para aqueles que se beneficiariam de uma distribuição mais ampla. + + A GPL foi projetada para impedir que os resultados de uma pesquisa sejam transferidos para produtos proprietários. Este passo é frequentemente considerado o último passo no pipeline tradicional de transferência de tecnologia e é geralmente o mais difícil mesmo sob as melhores circunstâncias; a GPL pretendia tornar isso impossível. + + + + + Vantagens da licença BSD + + Uma licença de estilo BSD é uma boa opção para pesquisas de longa duração ou outros projetos que precisam de um ambiente de desenvolvimento que: + + + + tem custo próximo a zero + irá evoluir durante um longo período de tempo + permite que qualquer pessoa mantenha a opção de comercializar os resultados finais com problemas legais mínimos. + + + Esta consideração final pode muitas vezes ser a dominante, como foi quando o projeto Apache decidiu sua licença: + + Este tipo de licença é ideal para promover o uso de um corpo de referência de código que implementa um protocolo para um serviço comum. Esta é outra razão pela qual a escolhemos para o grupo Apache - muitos de nós queriam que o HTTP sobrevivesse e se tornasse um verdadeiro padrão multipartidário, e não nos importaríamos nem um pouco se a Microsoft ou a Netscape escolhessem incorporar nosso mecanismo HTTP ou qualquer outro componente de nosso código em seus produtos, se isso ajudasse a manter o objetivo comum de manter o HTTP universal... Tudo isso significa que, estrategicamente falando, o projeto precisa manter ímpeto suficiente e que os participantes percebam um maior valor contribuindo com seu código para o projeto, mesmo código que teria valor se fosse mantido proprietário. + + Os desenvolvedores tendem a achar a licença BSD atrativa, pois ela mantém os problemas legais fora do caminho e permite que eles façam o que quiserem com o código. Em contraste, aqueles que esperam principalmente usar um sistema em vez de programá-lo, ou que esperam que outros evoluam o código, ou aqueles que não esperam ganhar a vida com seu trabalho associado ao sistema (como funcionários do governo), achem a GPL atraente, porque força o código desenvolvido por outros a ser dado a eles de volta e impede que os seus empregadores retenham os direitos autorais e, portanto, potencialmente "enterra" o problema de software órfão. Se você quiser forçar seus concorrentes a ajudá-lo, a GPL é atraente. + + Uma licença BSD não é simplesmente um presente. A pergunta por que devemos ajudar nossos concorrentes ou deixá-los roubar nosso trabalho? surge frequentemente em relação a uma licença BSD. Sob uma licença BSD, se uma empresa vier a dominar um nicho de produto que outros consideram estratégico, as outras empresas podem, com esforço mínimo, formar um mini consórcio visando restabelecer a paridade, contribuindo para uma variante BSD competitiva que aumente a competição e a justiça no mercado. Isso permite que cada empresa acredite que será capaz de lucrar com alguma vantagem que ela possa proporcionar, ao mesmo tempo em que contribui para a flexibilidade e eficiência econômica. Quanto mais rápido e fácil os membros cooperantes puderem fazer isso, maior sucesso eles terão. Uma licença BSD é essencialmente uma licença minimamente complicada que permite tal comportamento. + + Um efeito chave da GPL é fazer com que um sistema Open Source completo e competitivo seja amplamente disponibilizado ao custo de mídia, e isso é uma meta razoável. Uma licença no estilo BSD, em conjunto com consórcios ad-hoc de indivíduos, pode atingir essa meta sem destruir as premissas econômicas construídas em torno da implementação final do pipeline de transferência de tecnologia. + + + + + Recomendações Específicas para usar uma licença BSD + + + + A licença BSD é preferível para a transferência de resultados de pesquisa de uma maneira que seja largamente implantada e que mais beneficie uma economia. Como tal, as agências de financiamento de pesquisa, como a NSF, ONR e DARPA, devem encorajar nas fases iniciais dos projetos de pesquisa financiados, a adoção de licenças de estilo BSD para software, dados, resultados e hardware aberto. Eles também devem incentivar a formação de padrões baseados em sistemas Open Source implementados e projetos Open Source em andamento. + + A política do governo deve minimizar os custos e as dificuldades de passar da pesquisa para a implantação. Quando possível, os subsídios devem exigir que os resultados estejam disponíveis sob uma licença de estilo BSD amigável à comercialização. + + Em muitos casos, os resultados de longo prazo de uma licença de estilo BSD refletem com mais precisão os objetivos proclamados na carta de pesquisa das universidades do que ocorre quando os resultados são protegidos por direitos autorais ou patenteados e sujeitos ao licenciamento universitário proprietário. Existem evidências casuais de que as universidades são financeiramente mais bem recompensadas a longo prazo, divulgando resultados de pesquisa e apelando para doações de ex-alunos de sucesso comercial. + + As empresas há muito reconheceram que a criação de padrões de facto é uma técnica de marketing fundamental. A licença BSD serve bem a essa função se uma empresa tiver realmente uma vantagem exclusiva na evolução do sistema. A licença é legalmente atraente para o público mais amplo, enquanto a expertise da empresa garante o seu controle. Há momentos em que a GPL pode ser o veículo apropriado para uma tentativa de criar tal padrão, especialmente quando se tenta prejudicar ou cooptar outras pessoas. A GPL, no entanto, penaliza a evolução desse padrão, porque promove um conjunto em vez de um padrão comercialmente aplicável. O uso de tal conjunto constantemente sofre um aumento de problemas legais e comerciais. E pode não ser possível misturar padrões quando alguns estão sob a GPL e outros não. Um verdadeiro padrão técnico não deve obrigar a exclusão de outros padrões por razões não técnicas. + + As empresas interessadas em promover um padrão em evolução, que pode se tornar o núcleo dos produtos comerciais de outras empresas, devem ter cuidado com a GPL. Independentemente da licença usada, o software resultante geralmente será transferido para quem realmente faz a maioria das alterações de engenharia e que mais entende o estado do sistema. A GPL simplesmente adiciona mais atrito legal ao resultado. + + Grandes empresas, nas quais código Open Source é desenvolvido, devem estar cientes de que os programadores apreciam o Open Source porque ele deixa o software disponível para o funcionário quando ele mudar de empregador. Algumas empresas encorajam esse comportamento como uma vantagem de emprego, especialmente quando o software em questão não é diretamente estratégico. Trata-se, na verdade, de um benefício antecipado com possíveis custos de oportunidade perdidas, mas sem custos diretos. Incentivar os funcionários a trabalhar pela aclamação dos colegas fora da empresa é um benefício barato que uma uma empresa pode, por vezes, fornecer com desvantagem quase zero. + + Pequenas empresas com projetos de software vulneráveis ao software órfão, devem tentar usar a licença BSD sempre que possível. Empresas de todos os portes devem considerar a formação de tais projetos Open Source quando for vantajoso manter mínimas as despesas legais e organizacionais associadas a um verdadeiro projeto Open Source de estilo BSD. + + As organizações sem fins lucrativos devem participar de projetos Open Source sempre que possível. Para minimizar os problemas de engenharia de software, como a mistura de código sob diferentes licenças, as licenças no estilo BSD devem ser incentivadas. Desconfiar da GPL deve ser particularmente o caso de organizações sem fins lucrativos que interagem com o mundo de desenvolvimento. Em alguns locais onde a aplicação da lei se torna um exercício caro, a simplicidade da nova licença BSD, em comparação com a GPL, pode ser de considerável vantagem. + + + + + + + Conclusão + + Em contraste com a GPL, que é projetada para impedir a comercialização proprietária do código Open Source, a licença BSD impõe restrições mínimas sobre o comportamento futuro. Isso permite que o código BSD permaneça como código aberto ou se integre a soluções comerciais, à medida que as necessidades de um projeto ou empresa mudam. Em outras palavras, a licença BSD não se torna uma bomba-relógio legal em nenhum ponto do processo de desenvolvimento. + + Além disso, como a licença BSD não vem com a complexidade legal das licenças GPL ou LGPL, ela permite que desenvolvedores e empresas gastem seu tempo criando e promovendo um bom código, em vez de se preocupar se esse código viola algum licenciamento. + + + + + Adendos + + +[1] http://www.gnu.org/licenses/gpl.html + +[2] http://archives.cnn.com/2000/TECH/computing/03/28/cyberpatrol.mirrors/ + +[3] Open Source: the Unauthorized White Papers, Donald K. Rosenberg, IDG Books, + 2000. Quotes are from page 114, ``Effects of the GNU GPL''. + +[4] In the "What License to Use?" section of + http://www.oreilly.com/catalog/opensources/book/brian.html + +This whitepaper is a condensation of an original work available at +http://alumni.cse.ucsc.edu/~brucem/open_source_license.htm + + + +
      Added: head/pt_BR.ISO8859-1/articles/bsdl-gpl/pt_BR.po ============================================================================== --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/pt_BR.ISO8859-1/articles/bsdl-gpl/pt_BR.po Sat Sep 15 17:33:40 2018 (r52260) @@ -0,0 +1,1190 @@ +# $FreeBSD$ +# Danilo G. Baio , 2018. #zanata +# Edson Brandi , 2018. #zanata +# Rafael Mentz Aquino , 2018. #zanata +msgid "" +msgstr "" +"Project-Id-Version: PACKAGE VERSION\n" +"POT-Creation-Date: 2018-09-15 17:24+0000\n" +"PO-Revision-Date: 2018-09-15 05:02+0000\n" +"Last-Translator: Danilo G. Baio \n" +"Language-Team: \n" +"Language: pt_BR\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=UTF-8\n" +"Content-Transfer-Encoding: 8bit\n" +"X-Generator: Zanata 4.6.2\n" +"Plural-Forms: nplurals=2; plural=(n != 1)\n" + +#. Put one translator per line, in the form NAME , YEAR1, YEAR2 +msgctxt "_" +msgid "translator-credits" +msgstr "" +"Rafael Mentz Aquino, rafael@lk6.com.br, 2018\n" +"Edson Brandi, ebrandi@FreeBSD.org, 2018\n" +"Danilo G. Baio, dbaio@FreeBSD.org, 2018" + +#. (itstool) path: info/title +#: article.translate.xml:5 +msgid "Why you should use a BSD style license for your Open Source Project" +msgstr "" +"Por que você deve usar uma licença de estilo BSD em seu Projeto Open Source" + +#. (itstool) path: affiliation/address +#: article.translate.xml:9 +#, no-wrap +msgid "" +"brucem@alumni.cse.ucsc.edu\n" +" " +msgstr "" +"brucem@alumni.cse.ucsc.edu\n" +" " + +#. (itstool) path: authorgroup/author +#: article.translate.xml:8 +msgid "" +"BruceMontague <_:address-1/> " +msgstr "" +"BruceMontague <_:address-1/> " + +#. (itstool) path: legalnotice/para +#: article.translate.xml:15 +msgid "FreeBSD is a registered trademark of the FreeBSD Foundation." +msgstr "FreeBSD is a registered trademark of the FreeBSD Foundation." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:17 +msgid "" +"Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " +"and Xeon are trademarks or registered trademarks of Intel Corporation or its " +"subsidiaries in the United States and other countries." +msgstr "" +"Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium, " +"and Xeon are trademarks or registered trademarks of Intel Corporation or its " +"subsidiaries in the United States and other countries." + +#. (itstool) path: legalnotice/para +#: article.translate.xml:21 +msgid "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." +msgstr "" +"Many of the designations used by manufacturers and sellers to distinguish " +"their products are claimed as trademarks. Where those designations appear in " +"this document, and the FreeBSD Project was aware of the trademark claim, the " +"designations have been followed by the ™ or the ® symbol." + +#. (itstool) path: info/pubdate +#. (itstool) path: info/releaseinfo +#: article.translate.xml:29 article.translate.xml:31 +msgid "" +"$FreeBSD: head/en_US.ISO8859-1/articles/bsdl-gpl/article.xml 43184 " +"2013-11-13 07:52:45Z hrs $" +msgstr "$FreeBSD$" + +#. (itstool) path: sect1/title +#: article.translate.xml:35 +msgid "Introduction" +msgstr "Introdução" + +#. (itstool) path: sect1/para +#: article.translate.xml:37 +msgid "" +"This document makes a case for using a BSD style license for software and " +"data; specifically it recommends using a BSD style license in place of the " +"GPL. It can also be read as a BSD versus GPL Open Source License " +"introduction and summary." +msgstr "" +"Este documento apresenta argumentos para a utilização de uma licença de " +"estilo BSD para software e dados; especificamente recomenda utilizar uma " +"licença de estilo BSD no lugar de uma GPL. Também pode ser lido como uma " +"introdução e resumo das licenças de Projeto Open Source, BSD versus GPL." + +#. (itstool) path: sect1/title +#: article.translate.xml:44 +msgid "Very Brief Open Source History" +msgstr "Uma Breve História do Open Source" + +#. (itstool) path: sect1/para +#: article.translate.xml:46 +msgid "" +"Long before the term Open Source was used, software was " +"developed by loose associations of programmers and freely exchanged. " +"Starting in the early 1950's, organizations such as SHARE and DECUS developed much of the software that computer " +"hardware companies bundled with their hardware offerings. At that time " +"computer companies were in the hardware business; anything that reduced " +"software cost and made more programs available made the hardware companies " +"more competitive." +msgstr "" +"Muito antes do termo Open Source ser utilizado, o software " +"era desenvolvido por associações livres de programadores e os softwares eram " +"livremente trocados ou negociados. A partir do início dos anos 50, " +"organizações como a SHARE e " +"a DECUS desenvolviam grande " +"parte do software que as empresas de hardware empacotavam em suas ofertas. " +"Naquela época, as empresas de computadores estavam no negócio de hardware; " +"qualquer coisa que reduzisse o custo do software e disponibilizasse mais " +"programas tornava as empresas de hardware mais competitivas." + +#. (itstool) path: sect1/para +#: article.translate.xml:56 +msgid "" +"This model changed in the 1960's. In 1965 ADR developed the first licensed " +"software product independent of a hardware company. ADR was competing " +"against a free IBM package originally developed by IBM customers. ADR " +"patented their software in 1968. To stop sharing of their program, they " +"provided it under an equipment lease in which payment was spread over the " +"lifetime of the product. ADR thus retained ownership and could control " +"resale and reuse." +msgstr "" +"Este modelo mudou nos anos 60. Em 1965, a ADR desenvolveu o primeiro produto " +"de software licenciado e independente de uma empresa de hardware. A ADR " +"estava competindo contra um pacote gratuito da IBM que foi originalmente " +"desenvolvido por seus próprios clientes. A ADR patenteou seu software em " +"1968. Para interromper o compartilhamento de seu programa, eles forneceram " +"seu software sob leasing de equipamento, na qual o pagamento foi distribuído " +"durante a vida útil do produto. A ADR reteve a propriedade e pôde controlar " +"a revenda e a reutilização." + +#. (itstool) path: sect1/para +#: article.translate.xml:65 +msgid "" +"In 1969 the US Department of Justice charged IBM with destroying businesses " +"by bundling free software with IBM hardware. As a result of this suit, IBM " +"unbundled its software; that is, software became independent products " +"separate from hardware." +msgstr "" +"Em 1969, o Departamento de Justiça dos EUA acusou a IBM de destruir negócios " +"e empresas com seu agrupamento de software livre e hardware IBM. Como " +"resultado deste processo, a IBM separou seu software; isto é, os softwares " +"tornaram-se produtos independentes e separados do hardware." + +#. (itstool) path: sect1/para +#: article.translate.xml:71 +msgid "" +"In 1968 Informatics introduced the first commercial killer-app and rapidly " +"established the concept of the software product, the software company, and " +"very high rates of return. Informatics developed the perpetual license which " +"is now standard throughout the computer industry, wherein ownership is never " +"transferred to the customer." +msgstr "" +"Em 1968, a Informatics apresentou o primeiro software comercial " +"revolucionário e rapidamente foi estabelecido o conceito do produto de " +"software, da empresa de software e de taxas de retorno bem altas. A " +"Informatics desenvolveu a licença perpétua que agora é comum em toda a " +"indústria de computadores, onde a propriedade do software nunca é " +"transferida para o cliente." + +#. (itstool) path: sect1/title +#: article.translate.xml:80 +msgid "Unix from a BSD Licensing Perspective" +msgstr "Unix de uma Perspectiva de Licenciamento BSD" + +#. (itstool) path: sect1/para +#: article.translate.xml:82 +msgid "" +"AT&T, who owned the original Unix implementation, was a publicly " +"regulated monopoly tied up in anti-trust court; it was legally unable to " +"sell a product into the software market. It was, however, able to provide it " +"to academic institutions for the price of media." +msgstr "" +"A AT&T, que detinha a implementação original do Unix, era um monopólio " +"regulado publicamente e amarrado a um tribunal anti-trust; ela foi " +"legalmente impossibilitada de vender um produto no mercado de software. " +"Entretanto, ela podia fornece-lo a instituições acadêmicas pelo preço da " +"mídia." + +#. (itstool) path: sect1/para +#: article.translate.xml:88 +msgid "" +"Universities rapidly adopted Unix after an OS conference publicized its " +"availability. It was extremely helpful that Unix ran on the PDP-11, a very " +"affordable 16-bit computer, and was coded in a high-level language that was " +"demonstrably good for systems programming. The DEC PDP-11 had, in effect, an " +"open hardware interface designed to make it easy for customers to write " +"their own OS, which was common. As DEC founder Ken Olsen famously " +"proclaimed, software comes from heaven when you have good hardware." +msgstr "" +"As universidades adotaram rapidamente o Unix depois da divulgação de sua " +"disponibilidade em uma conferência de Sistema Operacional. Foi extremamente " +"útil o Unix rodar no PDP-11, um computador de 16 bits muito acessível na " +"época, e que foi codificado em uma linguagem de alto nível, que era " +"comprovadamente boa para a programação de sistemas. O DEC PDP-11 tinha, na " +"verdade, uma interface de hardware aberta, projetada para tornar mais fácil " +"para os clientes escreverem seus próprios sistemas operacionais, o que era " +"comum. O famoso fundador da DEC, Ken Olsen, proclamou que o software " +"vem do céu quando você tem um bom hardware." + +#. (itstool) path: sect1/para +#: article.translate.xml:98 +msgid "" +"Unix author Ken Thompson returned to his alma mater, University of " +"California Berkeley (UCB), in 1975 and taught the kernel line-by-line. This " +"ultimately resulted in an evolving system known as BSD (Berkeley Standard " +"Distribution). UCB converted Unix to 32-bits, added virtual memory, and " +"implemented the version of the TCP/IP stack upon which the Internet was " +"essentially built. UCB made BSD available for the cost of media, under what " +"became known as the BSD license. A customer purchased Unix " +"from AT&T and then ordered a BSD tape from UCB." +msgstr "" +"O autor do Unix, Ken Thompson, retornou à Universidade da Califórnia de " +"Berkeley (UCB) em 1975, e lecionou sobre o kernel linha por linha. Isso " +"acabou resultando em um sistema evoluído conhecido como BSD (Berkeley " +"Standard Distribution). A UCB converteu o Unix em 32 bits, adicionou memória " +"virtual e implementou a stack TCP/IP, a qual foi essencialmente necessária " +"para a construção da Internet. A UCB disponibilizou o BSD pelo custo da " +"mídia, e isso ficou conhecido como a licença BSD. Um cliente " +"comprava o Unix da AT&T e depois comprava uma fita BSD da UCB." + +#. (itstool) path: sect1/para +#: article.translate.xml:108 +msgid "" +"In the mid-1980s a government anti-trust case against ATT ended with the " +"break-up of ATT. ATT still owned Unix and was now able to sell it. ATT " +"embarked on an aggressive licensing effort and most commercial Unixes of the " +"day became ATT-derived." +msgstr "" +"Em meados da década de 80, um processo anti-trust governamental contra a ATT " +"resultou no seu desmembramento. A ATT ainda possuía o Unix e a partir " +"daquele momento podia vendê-lo. Então a ATT embarcou em um esforço agressivo " +"de licenciamento e a maioria dos Unixes comerciais da época tornaram-se " +"derivações do Unix ATT." + +#. (itstool) path: sect1/para +#: article.translate.xml:113 +msgid "" +"In the early 1990's ATT sued UCB over license violations related to BSD. UCB " +"discovered that ATT had incorporated, without acknowledgment or payment, " +"many improvements due to BSD into ATT's products, and a lengthy court case, " +"primarily between ATT and UCB, ensued. During this period some UCB " +"programmers embarked on a project to rewrite any ATT code associated with " +"BSD. This project resulted in a system called BSD 4.4-lite (lite because it " +"was not a complete system; it lacked 6 key ATT files)." +msgstr "" +"No início dos anos 90, a ATT processou a UCB por violações de licenças " +"relacionadas ao BSD. A UCB descobriu que a ATT havia incorporado, sem " +"reconhecimento ou pagamento, muitas melhorias nos produtos da ATT originadas " +"no BSD, e isso resultou em um longo processo judicial entre a ATT e a UCB. " +"Durante esse período, alguns programadores da UCB embarcaram em um projeto " +"para reescrever todos os códigos ATT que estavam associados ao BSD. Este " +"projeto resultou em um sistema chamado BSD 4.4-lite (lite porque não era um " +"sistema completo; faltavam 6 arquivos-chave ATT)." + +#. (itstool) path: sect1/para +#: article.translate.xml:122 +msgid "" +"A lengthy series of articles published slightly later in Dr. Dobbs magazine " +"described a BSD-derived 386 PC version of Unix, with BSD-licensed " +"replacement files for the 6 missing 4.4 lite files. This system, named " +"386BSD, was due to ex-UCB programmer William Jolitz. It became the original " +"basis of all the PC BSDs in use today." +msgstr "" +"Uma longa série de artigos foram publicados um pouco depois disso na revista " +"Dr. Dobbs, que descreviam uma versão do Unix derivada do BSD para PC 386, na " +"qual os 6 arquivos que estavam faltando no 4.4 lite foram substituídos por " +"arquivos de licença BSD. Este sistema, chamado 386BSD, foi devido ao ex " +"programador da UCB, William Jolitz. Ele se tornou a base original de todos " +"os BSD para PCs que estão atualmente em uso." + +#. (itstool) path: sect1/para +#: article.translate.xml:129 +msgid "" +"In the mid 1990s, Novell purchased ATT's Unix rights and a (then secret) " +"agreement was reached to terminate the lawsuit. UCB soon terminated its " +"support for BSD." +msgstr "" +"Em meados da década de 90, a Novell comprou os direitos do Unix da ATT e um " +"acordo (então secreto) foi fechado para encerrar o processo. A UCB logo " +"encerrou seu suporte para o BSD." + +#. (itstool) path: sect1/title +#: article.translate.xml:135 +msgid "The Current State of FreeBSD and BSD Licenses" +msgstr "O Estado Atual das Licenças FreeBSD e BSD" + +#. (itstool) path: sect1/para +#: article.translate.xml:137 +msgid "" +"The so-called new BSD license applied to FreeBSD within the last few " +"years is effectively a statement that you can do anything with the program " +"or its source, but you do not have any warranty and none of the authors has " +"any liability (basically, you cannot sue anybody). This new BSD license is " +"intended to encourage product commercialization. Any BSD code can be sold or " +"included in proprietary products without any restrictions on the " +"availability of your code or your future behavior." +msgstr "" +"A chamada nova licença BSD aplicada ao FreeBSD nos últimos anos é " +"efetivamente uma afirmação de que você pode fazer qualquer coisa com o " +"programa ou seu código fonte, mas você não tem nenhuma garantia e nenhum dos " +"autores tem qualquer responsabilidade (basicamente, você não pode processar " +"ninguém). Esta nova licença BSD destina-se a incentivar a comercialização de " +"produtos. Qualquer código BSD pode ser vendido ou incluído em produtos " +"proprietários, sem quaisquer restrições quanto à disponibilidade do seu " +"código ou seu comportamento futuro." + +#. (itstool) path: sect1/para +#: article.translate.xml:147 +msgid "" +"Do not confuse the new BSD license with public domain. While " +"an item in the public domain is also free for all to use, it has no owner." +msgstr "" +"Não confunda a nova licença BSD com domínio público. Enquanto " +"um item no domínio público também é gratuito para todos, ele não possui um " +"proprietário." + +#. (itstool) path: sect1/title +#: article.translate.xml:154 +msgid "The origins of the GPL" +msgstr "As origens da GPL" + +#. (itstool) path: sect1/para +#: article.translate.xml:156 +msgid "" +"While the future of Unix had been so muddled in the late 1980s and early " +"1990s, the GPL, another development with important licensing considerations, " +"reached fruition." +msgstr "" +"Enquanto o futuro do Unix era tão confuso no final dos anos 80 e início dos " +"anos 90, a GPL, um outro desenvolvimento com importantes considerações sobre " +"licenciamento, surgiu." + +#. (itstool) path: sect1/para +#: article.translate.xml:160 +msgid "" +"Richard Stallman, the developer of Emacs, was a member of the staff at MIT " +"when his lab switched from home-grown to proprietary systems. Stallman " +"became upset when he found that he could not legally add minor improvements " +"to the system. (Many of Stallman's co-workers had left to form two companies " +"based on software developed at MIT and licensed by MIT; there appears to " +"have been disagreement over access to the source code for this software). " +"Stallman devised an alternative to the commercial software license and " +"called it the GPL, or \"GNU Public License\". He also started a non-profit " +"foundation, the Free Software " +"Foundation (FSF), which intended to develop an entire operating " +"system, including all associated software, that would not be subject to " +"proprietary licensing. This system was called GNU, for \"GNU is Not Unix\"." +msgstr "" +"Richard Stallman, o desenvolvedor do Emacs, era membro da equipe do MIT " +"quando seu laboratório mudou de sistemas domésticos para sistemas " +"proprietários. Stallman ficou chateado quando descobriu que não podia " +"adicionar legalmente pequenas melhorias ao sistema. (Muitos dos colegas de " +"trabalho de Stallman tinham saído para formar duas empresas com base em " +"software desenvolvido no MIT e licenciado pelo MIT; parece ter havido " +"desacordo sobre o acesso ao código-fonte desse software). Stallman criou uma " +"alternativa para a licença de software comercial e a chamou de GPL, ou \"GNU " +"Public License\". Ele também fundou uma fundação sem fins lucrativos, a " +"Free Software Foundation " +"(FSF), que pretendia desenvolver um sistema operacional completo, incluindo " +"todos os softwares associados, e que não estaria sujeito a uma licença " +"proprietária. Este sistema foi chamado de GNU, que significa \"GNU is Not " +"Unix\"." + +#. (itstool) path: sect1/para +#: article.translate.xml:175 +msgid "" +"The GPL was designed to be the antithesis of the standard proprietary " +"license. To this end, any modifications that were made to a GPL program were " +"required to be given back to the GPL community (by requiring that the source " +"of the program be available to the user) and any program that used or linked " +"to GPL code was required to be under the GPL. The GPL was intended to keep " +"software from becoming proprietary. As the last paragraph of the GPL states:" +msgstr "" +"A GPL foi projetada para ser o oposto da licença proprietária padrão. Para " +"este fim, quaisquer modificações que eram feitas a um programa GPL tinham " +"que ser devolvidas à comunidade GPL (exigindo que o código fonte do programa " +"fosse disponibilizado para o usuário) e que qualquer programa que utilizar " +"ou linkar com código GPL, teria que estar sob a GPL. A GPL pretendia impedir " +"que o software se tornasse proprietário. Como o último parágrafo da GPL " +"afirma:" + +#. (itstool) path: sect1/para +#: article.translate.xml:184 +msgid "" +"This General Public License does not permit incorporating your " +"program into proprietary programs.[1]" +msgstr "" +"This General Public License does not permit incorporating your " +"program into proprietary programs.[1]" + +#. (itstool) path: sect1/para +#: article.translate.xml:188 +msgid "" +"The GPL is a complex license so here are some rules of thumb when " +"using the GPL:" +msgstr "" +"A GPL é uma licença complexa, então aqui estão algumas regras " +"básicas ao usar a GPL:" + +#. (itstool) path: listitem/para +#: article.translate.xml:194 +msgid "" +"you can charge as much as you want for distributing, supporting, or " +"documenting the software, but you cannot sell the software itself." +msgstr "" +"você pode cobrar o quanto quiser para distribuir, dar suporte ou documentar " +"o software, mas não pode vender o software em si." + +#. (itstool) path: listitem/para +#: article.translate.xml:198 +msgid "" +"the rule-of-thumb states that if GPL source is required for a program to " +"compile, the program must be under the GPL. Linking statically to a GPL " +"library requires a program to be under the GPL." +msgstr "" +"a regra básica indica que, se um código fonte GPL for necessário para um " +"programa compilar, então o programa deve estar sob a GPL. Linkar " +"estaticamente a uma biblioteca GPL requer que um programa esteja sob a GPL." + +#. (itstool) path: listitem/para +#: article.translate.xml:203 +msgid "" +"the GPL requires that any patents associated with GPLed software must be " +"licensed for everyone's free use." +msgstr "" +"a GPL exige que quaisquer patentes associadas ao software GPL sejam " +"licenciadas para uso livre de todos." + +#. (itstool) path: listitem/para +#: article.translate.xml:207 +msgid "" +"simply aggregating software together, as when multiple programs are put on " +"one disk, does not count as including GPLed programs in non-GPLed programs." +msgstr "" +"simplesmente agregar softwares juntos, como quando vários programas são " +"colocados em um disco, não conta como inclusão de programas GPL em programas " +"não-GPL." + +#. (itstool) path: listitem/para +#: article.translate.xml:212 +msgid "" +"output of a program does not count as a derivative work. This enables the " +"gcc compiler to be used in commercial environments without legal problems." +msgstr "" +"o que se resulta de um programa não conta como um trabalho derivado. Isso " +"permite que o compilador gcc seja utilizado em ambientes comerciais sem " +"problemas legais." + +#. (itstool) path: listitem/para +#: article.translate.xml:216 +msgid "" +"since the Linux kernel is under the GPL, any code statically linked with the " +"Linux kernel must be GPLed. This requirement can be circumvented by " +"dynamically linking loadable kernel modules. This permits companies to " +"distribute binary drivers, but often has the disadvantage that they will " +"only work for particular versions of the Linux kernel." +msgstr "" +"como o kernel do Linux está sob a GPL, qualquer código estaticamente linkado " +"ao kernel do Linux deve ser GPL. Este requisito pode ser contornado ao " +"linkar dinamicamente módulos carregáveis do kernel. Isso permite que as " +"empresas distribuam drivers binários, mas geralmente tem a desvantagem de " +"que eles só funcionarão para versões específicas do kernel do Linux." + +#. (itstool) path: sect1/para +#: article.translate.xml:224 +msgid "" +"Due in part to its complexity, in many parts of the world today the " +"legalities of the GPL are being ignored in regard to Linux and related " +"software. The long-term ramifications of this are unclear." +msgstr "" +"Devido em parte à sua complexidade, em muitas partes do mundo hoje as " +"legalidades da GPL estão sendo ignoradas em relação ao Linux e softwares " +"relacionados. As ramificações de longo prazo por causa disso não são claras." + +#. (itstool) path: sect1/title +#: article.translate.xml:232 +msgid "The origins of Linux and the LGPL" +msgstr "As origens do Linux e da LGPL" + +#. (itstool) path: sect1/para +#: article.translate.xml:234 +msgid "" +"While the commercial Unix wars raged, the Linux kernel was developed as a PC " +"Unix clone. Linus Torvalds credits the existence of the GNU C compiler and " +"the associated GNU tools for the existence of Linux. He put the Linux kernel " +"under the GPL." +msgstr "" +"Enquanto as guerras comerciais do Unix se intensificavam, o kernel do Linux " +"foi desenvolvido como um clone do PC Unix. Linus Torvalds credita a " +"existência do compilador GNU C e das ferramentas GNU associadas pela " +"existência do Linux. Ele colocou o kernel do Linux sob a GPL." + +#. (itstool) path: sect1/para +#: article.translate.xml:239 +msgid "" +"Remember that the GPL requires anything that statically links to any code " +"under the GPL also be placed under the GPL. The source for this code must " +"thus be made available to the user of the program. Dynamic linking, however, " +"is not considered a violation of the GPL. Pressure to put proprietary " +"applications on Linux became overwhelming. Such applications often must link " +"with system libraries. This resulted in a modified version of the GPL called " +"the LGPL (\"Library\", since renamed to \"Lesser\", GPL). The LGPL " +"allows proprietary code to be linked to the GNU C library, glibc. You do not " +"have to release the source to code which has been dynamically linked to an " +"LGPLed library." +msgstr "" +"Lembre-se de que a GPL requer que qualquer software que seja estaticamente " +"linkado a um código GPL, também seja colocado sob a GPL. O código fonte " +"desse software deve ser disponibilizado ao usuário do programa. O link " +"dinâmico, no entanto, não é considerado uma violação da GPL. A pressão para " +"colocar aplicativos proprietários no Linux tornou-se esmagadora. Tais " +"aplicativos geralmente precisavam se linkar a bibliotecas do sistema. Isso " +"resultou em uma versão modificada da GPL chamada LGPL (\"Library\", e " +"depois renomeado para \"Lesser\", GPL). A LGPL permite que o código " +"proprietário faça link com à biblioteca GNU C, glibc. Você não precisa " +"liberar o código-fonte para um software que foi linkado dinamicamente a uma " +"biblioteca LGPL." + +#. (itstool) path: sect1/para +#: article.translate.xml:252 +msgid "" +"If you statically link an application with glibc, such as is often required " +"in embedded systems, you cannot keep your application proprietary, that is, " +"the source must be released. Both the GPL and LGPL require any modifications " +"to the code directly under the license to be released." +msgstr "" +"Se você linkar estaticamente uma aplicação com a glibc, o que geralmente é " +"necessário em sistemas embarcados, não será possível manter seu aplicativo " +"proprietário, isto é, o código fonte deve ser liberado. Tanto a GPL quanto a " +"LGPL requerem que qualquer software sob suas licenças liberem quaisquer " +"modificações no código fonte." + +#. (itstool) path: sect1/title +#: article.translate.xml:261 +msgid "Open Source licenses and the Orphaning Problem" +msgstr "Licenças Open Source e o Problema dos Softwares Orfãos" + +#. (itstool) path: sect1/para +#: article.translate.xml:263 +msgid "" +"One of the serious problems associated with proprietary software is known as " +"orphaning. This occurs when a single business failure or " +"change in a product strategy causes a huge pyramid of dependent systems and " +"companies to fail for reasons beyond their control. Decades of experience " +"have shown that the momentary size or success of a software supplier is no " +"guarantee that their software will remain available, as current market " +"conditions and strategies can change rapidly." +msgstr "" +"Um problema sério associado ao software proprietário é conhecido como " +"orphaning. Isso ocorre quando um simples negócio falha ou " +"quando uma mudança na estratégia de um produto faz com que uma cadeia de " +"sistemas e empresas que dependiam deste produto, também falhem por motivos " +"que estão fora de seus controles. Décadas de experiência mostraram que o " +"tamanho ou o sucesso momentâneo de um fornecedor de software não é uma " +"garantia de que seu software permanecerá disponível, pois as condições e " +"estratégias atuais do mercado podem mudar rapidamente." + +#. (itstool) path: sect1/para +#: article.translate.xml:272 +msgid "" +"The GPL attempts to prevent orphaning by severing the link to proprietary " +"intellectual property." +msgstr "" +"A GPL tenta impedir o software órfão cortando o link para a propriedade " +"intelectual proprietária." + +#. (itstool) path: sect1/para +#: article.translate.xml:275 +msgid "" +"A BSD license gives a small company the equivalent of software-in-escrow " +"without any legal complications or costs. If a BSD-licensed program becomes " +"orphaned, a company can simply take over, in a proprietary manner, the " +"program on which they are dependent. An even better situation occurs when a " +"BSD code-base is maintained by a small informal consortium, since the " +"development process is not dependent on the survival of a single company or " +"product line. The survivability of the development team when they are " +"mentally in the zone is much more important than simple physical " +"availability of the source code." +msgstr "" +"Uma licença BSD concede a uma pequena empresa o equivalente a um software-in-" +"escrow sem quaisquer complicações ou custos legais. Se um programa " +"licenciado pela BSD se torna órfão, uma empresa pode simplesmente assumir, " +"de maneira proprietária, o programa do qual eles são dependentes. Uma " +"situação ainda melhor ocorre quando uma base de código BSD é mantida por um " +"pequeno consórcio informal, uma vez que o processo de desenvolvimento não " +"depende da sobrevivência de uma única empresa ou de uma linha de produtos. A " +"capacidade de sobrevivência da equipe de desenvolvimento quando eles estão " +"mentalmente seguros é muito mais importante do que a simples disponibilidade " +"física do código-fonte." + +#. (itstool) path: sect1/title +#: article.translate.xml:289 +msgid "What a license cannot do" +msgstr "O que uma licença não pode fazer" + +#. (itstool) path: sect1/para +#: article.translate.xml:291 +msgid "" +"No license can guarantee future software availability. Although a copyright " +"holder can traditionally change the terms of a copyright at anytime, the " +"presumption in the BSD community is that such an attempt simply causes the " +"source to fork." +msgstr "" +"Nenhuma licença pode garantir disponibilidade futura do software. Embora um " +"detentor de direitos autorais possa tradicionalmente mudar os termos de um " +"direito autoral a qualquer momento, a presunção na comunidade BSD é de que " +"tal tentativa simplesmente faz com que o código fonte seja derivado (fork)." + +#. (itstool) path: sect1/para +#: article.translate.xml:297 +msgid "" +"The GPL explicitly disallows revoking the license. It has occurred, however, " +"that a company (Mattel) purchased a GPL copyright (cphack), revoked the " +"entire copyright, went to court, and prevailed [2]. That is, they legally " +"revoked the entire distribution and all derivative works based on the " +"copyright. Whether this could happen with a larger and more dispersed " +"distribution is an open question; there is also some confusion regarding " +"whether the software was really under the GPL." +msgstr "" +"A GPL proíbe explicitamente a revogação da licença. Ocorreu no entanto, que " +"uma empresa (Mattel) comprou um copyright GPL (cphack), e revogou todo o " +"direito autoral, foi a tribunal e conseguiu prevalecer [2]. Ou seja, eles " +"revogaram legalmente toda a distribuição e todos os trabalhos derivados com " +"base nos direitos autorais. Se isso pode acontecer com uma distribuição " +"maior e mais dispersa, fica uma questão em aberto; Há também alguma confusão " +"sobre se o software estava realmente sob a GPL." + +#. (itstool) path: sect1/para +#: article.translate.xml:307 +msgid "" +"In another example, Red Hat purchased Cygnus, an engineering company that " +"had taken over development of the FSF compiler tools. Cygnus was able to do " +"so because they had developed a business model in which they sold support " +"for GNU software. This enabled them to employ some 50 engineers and drive " +"the direction of the programs by contributing the preponderance of " +"modifications. As Donald Rosenberg states \"projects using licenses like the " +"GPL...live under constant threat of having someone take over the project by " +"producing a better version of the code and doing it faster than the original " +"owners.\" [3]" +msgstr "" +"Em outro exemplo, a Red Hat comprou a Cygnus, uma empresa de engenharia que " +"havia assumido o desenvolvimento das ferramentas de compilação da FSF. A " +"Cygnus foi capaz de fazer isso porque eles desenvolveram um modelo de " +"negócios no qual eles vendiam suporte para o software GNU. Isso permitiu que " +"eles empregassem cerca de 50 engenheiros e os orientassem na direção dos " +"programas, contribuindo com a preponderância de modificações. Como afirma " +"Donald Rosenberg, \"projetos usando licenças como a GPL ... vivem sob " +"constante ameaça de que alguém assuma o projeto produzindo uma versão melhor " +"do código e fazendo isso mais rápido que os proprietários originais\". [3]" + +#. (itstool) path: sect1/title +#: article.translate.xml:321 +msgid "GPL Advantages and Disadvantages" +msgstr "Vantagens e Desvantagens da GPL" + +#. (itstool) path: sect1/para +#: article.translate.xml:323 +msgid "" +"A common reason to use the GPL is when modifying or extending the gcc " +"compiler. This is particularly apt when working with one-off specialty CPUs " +"in environments where all software costs are likely to be considered " +"overhead, with minimal expectations that others will use the resulting " +"compiler." +msgstr "" +"Um motivo comum para usar a GPL é ao modificar ou criar extensões ao " +"compilador gcc. Isso é particularmente apropriado quando se trabalha com " +"CPUs especiais únicas em ambientes em que todos os custos de software " +"provavelmente são considerados como despesas gerais, com expectativas " +"mínimas de que outros usarão o compilador resultante." + +#. (itstool) path: sect1/para +#: article.translate.xml:329 +msgid "" +"The GPL is also attractive to small companies selling CDs in an environment " +"where \"buy-low, sell-high\" may still give the end-user a very inexpensive " +"product. It is also attractive to companies that expect to survive by " +"providing various forms of technical support, including documentation, for " +"the GPLed intellectual property world." +msgstr "" +"A GPL também é atraente para pequenas empresas que vendem CDs em um ambiente " +"em que o \"buy-low, sell-high\" ainda pode dar ao usuário final um produto " +"muito barato. Também é atraente para empresas que esperam sobreviver " +"fornecendo várias formas de suporte técnico, incluindo documentação, para o " +"mundo da propriedade intelectual GPL." + +#. (itstool) path: sect1/para +#: article.translate.xml:336 +msgid "" +"A less publicized and unintended use of the GPL is that it is very favorable " +"to large companies that want to undercut software companies. In other words, " +"the GPL is well suited for use as a marketing weapon, potentially reducing " +"overall economic benefit and contributing to monopolistic behavior." +msgstr "" *** DIFF OUTPUT TRUNCATED AT 1000 LINES ***