Arquivo da tag: Linux

Atualizando o VMPlayer 15.5.6 – Fedora 32

Uso o VMware Player no meu Fedora, tudo o que eu preciso funciona perfeitamente. Somente quando sai uma nova versão do kernel eu preciso recompilar o módulo do vmware para funcionar corretamente, faz parte :)

Eu já possuía o VMware Player 15.5.1 instalado (ok, um pouco desatualizado) e funcionando anteriormente no meu Fedora.

Para manter atualizado, na teoria bastaria baixar o bundle novo do VMware e instalar como sempre fiz, mas com a versão 15.5.6 ocorreu o erro abaixo:

[gp@gp]$ sudo ./VMware-Player-15.5.6-16341506.x86_64.bundle
Extracting VMware Installer…done.
/tmp/tmppx9x6f1l.vmis.env:4: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
import imp
/tmp/vmis.eoJqmS/install/vmware-installer/vmis-launcher: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

Executando como root direto (sem o sudo), o mesmo erro ocorreu:

[root@gp]# ./VMware-Player-15.5.6-16341506.x86_64.bundle
Extracting VMware Installer…done.
/tmp/tmpffuk0k_k.vmis.env:4: DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses
import imp
/tmp/vmis.ab6XDZ/install/vmware-installer/vmis-launcher: error while loading shared libraries: libbz2.so.1.0: cannot open shared object file: No such file or directory

Pesquisando um pouco, vi como alternativa executar o binário vmware-instaler (vi isso em https://communities.vmware.com/message/2967312#2967312) e passar o bundle como parâmetro (para isso, uma versão anterior já precisa estar instalada na máquina, o que era meu caso), mas outro erro ocorre:

[root@gp ]# vmware-installer -i VMware-Player-15.5.6-16341506.x86_64.bundle
Installing VMware VMX 15.5.6
Configuring…bora/lib/string/str.c:284 Buffer too small
[############################################### ] 67%
VMware Workstation Error:
VMware Workstation unrecoverable error: (host-10070)
bora/lib/string/str.c:284 Buffer too small
You can request support.

Depois de penar um pouco, encontrei num blog (https://andrescrivener.wordpress.com/2019/09/26/erro-ao-instalar-vmware-player-no-linux-bora-lib-string-str-c284-buffer-too-small/comment-page-1/) a solução, executar com LC_ALL=C setado:

[root@gp]# LC_ALL=C vmware-installer -i VMware-Player-15.5.6-16341506.x86_64.bundle
Installing VMware Player 15.5.6
Configuring…
[######################################################################] 100%
Installation was successful.


Sucesso !!!

Agora é só instalar o patch disponível em https://github.com/mkubecek/vmware-host-modules para o módulo do kernel subir corretamente.

wget https://github.com/mkubecek/vmware-host-modules/archive/player-15.5.6.tar.gz
cd vmware-host-modules-player-15.5.6/
make clean
make
make install
systemctl restart vmware
systemctl restart vmware-USBArbitrator.service

E executar o vmplayer:

/usr/lib/vmware/bin/vmplayer

Pronto, tudo funcionando normalmente.

Este post não é bem um tutorial, é mais para reunir a solução de dois problemas distintos que tive ao atualizar o VMware e que podem auxiliar outras pessoas.

Adicionando um novo disco no Linux

Como adicionar um novo disco (estamos falado de HD e não de qualquer outro tipo de mídia) num Linux?

O escopo deste post é mostrar como configurar um novo disco num Linux, pulando a parte “hardware” da coisa, ou seja, não vamos falar de cabeamento, parafusos e eventuais jumpers.

Uma vez que o disco foi instalado fisicamente na máquina, devemos identificá-lo para prepará-lo e então poder utilizá-lo.

Primeiramente, com o comando “df”, vamos verificar qual é o nosso disco atual:

[root@localhost ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             19306788   2809356  15516696  16% /
tmpfs                   515428        88    515340   1% /dev/shm
/dev/sda1               297485     31238    250887  12% /boot

 

Com a saída do comando, verificamos que o disco atualmente utilizado é o /dev/sda.

Agora, para identificar o disco novo, podemos executar o comando “dmesg” e procurar por “disk”:

[root@localhost ~]# dmesg|grep disk
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 0:0:0:0: [sda] Attached SCSI disk

 

Se nosso disco em uso é o “sda” e agora temos um “sdb”, acabamos de identificar nosso disco recém adicionado.

Com o disco identificado, agora vamos prepará-lo para utilizar no Linux. Preparar consiste basicamente em particionar e formatar o disco.

Para particionar, usaremos o comando “fdisk”:

[root@localhost ~]# fdisk /dev/sdb

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

 

Ok, vamos sair do modo de compatibilidade DOS e utilizar setores como medida de unidades:

[root@localhost ~]# fdisk -cu /dev/sdb
Command (m for help):

 

No fdisk, digitamos “p” para mostrar informações sobre o disco como as partições atuais (que no nosso caso, não existem):

Command (m for help): p
Disk /dev/sdb: 10.7 GB, 10737418240 bytes
 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x62e8c07a
Device Boot      Start         End      Blocks   Id  System
Command (m for help):

 

Se não temos partições, vamos criar uma:

 Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (2048-20971519, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-20971519, default 20971519):
Using default value 20971519
Command (m for help):

 

E então listar essa nova partição criada:

Command (m for help): p

Disk /dev/sdb: 10.7 GB, 10737418240 bytes
107 heads, 17 sectors/track, 11529 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x62e8c07a

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1            2048    20971519    10484736   83  Linux
Command (m for help):

 

Por padrão, o tipo de partição criada é “Linux”. Este tipo é utilizado para sistemas de arquivo do tipo Ext2/Ext3/Ext4, por exemplo.

Se estiver apenas adicionando um disco e não quiser utilizá-lo com LVM, pode ignorar os próximos passos, salvar as alterações na tabela de partições (digitando “w” no fdisk) e ir direto para o comando “mkfs.ext4”, mais ao final do texto. Caso queira utilizar LVM, continue lendo.

Para  utilizar a partição com LVM, deve-se mudar o tipo de partição. Para isso, ainda no fdisk, digite “t” e mude o tipo para “8e” (Linux LVM):

Command (m for help): t
 Selected partition 1
 Hex code (type L to list codes): 8e
 Changed system type of partition 1 to 8e (Linux LVM)
Command (m for help):

 

Vamos listar a tabela de partições para verificar as modificações:

Command (m for help): p
Disk /dev/sdb: 10.7 GB, 10737418240 bytes
 255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x62e8c07a
Device Boot      Start         End      Blocks   Id  System
 /dev/sdb1            2048    20971519    10484736   8e  Linux LVM
Command (m for help):

 

Se estiverem OK, basta salvar as mudanças e sair do fdisk (comando “w”):

Command (m for help): w
 The partition table has been altered!
Calling ioctl() to re-read partition table.
 Syncing disks.

 

De volta ao bash, podemos verificar se as mudanças realmente foram salvas com:

[root@localhost ~]# fdisk -cul /dev/sdb
Disk /dev/sdb: 10.7 GB, 10737418240 bytes
 107 heads, 17 sectors/track, 11529 cylinders, total 20971520 sectors
 Units = sectors of 1 * 512 = 512 bytes
 Sector size (logical/physical): 512 bytes / 512 bytes
 I/O size (minimum/optimal): 512 bytes / 512 bytes
 Disk identifier: 0x62e8c07a
Device Boot      Start         End      Blocks   Id  System
 /dev/sdb1            2048    20971519    10484736   8e  Linux LVM

 

Até aqui temos partição criada e tipo modificado para Linux LVM. Devemos então criar um volume físico para o LVM. Isso pode ser feito com o comando “pvcreate”:

[root@localhost ~]# pvcreate /dev/sdb1
 Writing physical volume data to disk "/dev/sdb1"
 Physical volume "/dev/sdb1" successfully created

 

Então vamos visualizar algumas informações sobre este novo volume físico criado:

 [root@localhost ~]#  pvs
 PV         VG   Fmt  Attr PSize  PFree
 /dev/sdb1       lvm2 a--  10.00g 10.00g

 

E visualizar os atributos deste volume:

 [root@localhost ~]# # pvdisplay
 "/dev/sdb1" is a new physical volume of "10.00 GiB"
 --- NEW Physical volume ---
 PV Name               /dev/sdb1
 VG Name
 PV Size               10.00 GiB
 Allocatable           NO
 PE Size               0
 Total PE              0
 Free PE               0
 Allocated PE          0
 PV UUID               XqqgNn-WYhy-NFA8-ntae-hVVw-4wrl-uHy2fK

 

Em um volume físico, precisamos criar Volume Groups, que são as estruturas lógicas onde finalmente vamos armazenar os dados.

Para listar informações sobre os volume groups, usamos o comando “lvs”:

[root@localhost ~]# lvs
 No volume groups found

 

No nosso caso, ainda não temos nenhum criado. Vamos criar um volume group chamado “vg_teste” neste disco que acabamos de particionar e adicionar um volume físico, para isso, usaremos o comando “vgcreate”:

[root@localhost ~]# vgcreate vg_teste /dev/sdb1
 Volume group "vg_teste" successfully created

 

Para listar informações sobre os Volume Groups, podemos usar o comando “vgs”:

[root@localhost ~]# vgs
 VG       #PV #LV #SN Attr   VSize  VFree
 vg_teste   1   0   0 wz--n- 10.00g 10.00g

 

Se executarmos o comando “pvs” novamente iremos observar que a coluna “VG” agora está preenchida com o nosso “vg_teste” recém criado:

[root@localhost ~]# pvs
 PV         VG       Fmt  Attr PSize  PFree
 /dev/sdb1  vg_teste lvm2 a--  10.00g 10.00g

 

Tendo um volume group criado, podemos criar um ou mais volumes lógicos. A grande vantagem de trabalharmos com volumes é poder facilmente adicionar e/ou remover espaço de um volume lógico. Se tivermos espaço livre disponível no volume group, podemos adicionar espaço a um volume lógico sem sequer ter que parar o sistema.

Para criar um volume lógico, usamos o comando “lvcreate”:

[root@localhost ~]# lvcreate -L 10G -n lv_teste vg_teste
 Volume group "vg_teste" has insufficient free space (2559 extents): 2560 required.

 

Um ponto a se observar é que quando criamos o volume group alocamos 10 Gbytes para o mesmo mas agora não pudemos fazer o mesmo para o volume lógico, por que?

Todos os volumes são divididos em partes menores, chamadas “extents”. Uma extent é a menor parte alocável de um volume e, sempre que criamos um volume, uma extent é reservada e não podemos utilizá-la. Então nossa possibilidade de uso de um volume pode ser definida como “tamanho total do volume menos uma extent”.

Vamos ver com “vgdisplay” quantas extents temos livres no nosso volume group. Basta procurar a linha “Free  PE / Size” e observarmos que temos 2559 ao invés das 2560 necessárias para 10 Gbytes:

[root@localhost ~]# vgdisplay
 --- Volume group ---
 VG Name               vg_teste
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  1
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                0
 Open LV               0
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               10.00 GiB
 PE Size               4.00 MiB
 Total PE              2559
 Alloc PE / Size       0 / 0
 Free  PE / Size       2559 / 10.00 GiB
 VG UUID               Mv0C69-2t56-tPSI-rNX9-cUcj-r28q-89tgSp

 

Então vamos criar um volume lógico novamente mas, ao invés de pedirmos 10 GB de tamanho (parâmetro “-L 10G”), vamos pedir 2559 extents (parâmetro “-l 2559”):

[root@localhost ~]# lvcreate -l 2559 -n lv_teste vg_teste
 Logical volume "lv_teste" created

Então executamos vgdisplay novamente para verificar que a linha “Alloc PE / Size” passou a mostrar “2559 / 10.00 GiB” ao invés de “0 / 0” que estava anteriormente:

 [root@localhost ~]# vgdisplay
 --- Volume group ---
 VG Name               vg_teste
 System ID
 Format                lvm2
 Metadata Areas        1
 Metadata Sequence No  2
 VG Access             read/write
 VG Status             resizable
 MAX LV                0
 Cur LV                1
 Open LV               0
 Max PV                0
 Cur PV                1
 Act PV                1
 VG Size               10.00 GiB
 PE Size               4.00 MiB
 Total PE              2559
 Alloc PE / Size       2559 / 10.00 GiB
 Free  PE / Size       0 / 0
 VG UUID               Mv0C69-2t56-tPSI-rNX9-cUcj-r28q-89tgSp

 

O comando pvdisplay também mostrará que temos todo o volume alocado:

[root@localhost ~]# pvdisplay
 --- Physical volume ---
 PV Name               /dev/sdb1
 VG Name               vg_teste
 PV Size               10.00 GiB / not usable 3.00 MiB
 Allocatable           yes (but full)
 PE Size               4.00 MiB
 Total PE              2559
 Free PE               0
 Allocated PE          2559
 PV UUID               TvGETI-FbsG-0UWt-4v0N-TwT5-bfnj-IZZsQ0

 

E o comando “lvs” listará todos os volumes lógicos criados:

[root@localhost ~]# lvs
 LV       VG       Attr     LSize  Pool Origin Data%  Move Log Copy%  Convert
 lv_teste vg_teste -wi-a--- 10.00g

 

Com todos os passos executados, basta formatar o volume lógico com o comando “mkfs.ext4”. Neste ponto, se escolheu não utilizar volumes, substitua o caminho para sua partição que neste caso seria /dev/sdb1:

[root@localhost ~]# mkfs.ext4 /dev/mapper/vg_teste-lv_teste
 mke2fs 1.41.12 (17-May-2010)
 Filesystem label=
 OS type: Linux
 Block size=4096 (log=2)
 Fragment size=4096 (log=2)
 Stride=0 blocks, Stripe width=0 blocks
 655360 inodes, 2620416 blocks
 131020 blocks (5.00%) reserved for the super user
 First data block=0
 Maximum filesystem blocks=2684354560
 80 block groups
 32768 blocks per group, 32768 fragments per group
 8192 inodes per group
 Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632
Writing inode tables: done
 Creating journal (32768 blocks): done
 Writing superblocks and filesystem accounting information: done
This filesystem will be automatically checked every 27 mounts or
 180 days, whichever comes first.  Use tune2fs -c or -i to override.

 

Poderíamos parar por aqui mas não quero que meu disco seja testado a cada 27 montagens ou 180 dias, que são os valores padrão. Então, com “tune2fs”, vamos mudar para ele nunca mais checar automaticamente:

[root@localhost ~]# tune2fs -c0 -i 0 /dev/mapper/vg_teste-lv_teste
 tune2fs 1.41.12 (17-May-2010)
 Setting maximal mount count to -1
 Setting interval between checks to 0 seconds

 

E para montar o volume automaticamente em todo boot do sistema, vamos colocá-lo no arquivo /etc/fstab. Para isso, vamos identificar o “id” do volume, com o comando “blkid”:

[root@localhost ~]# blkid /dev/mapper/vg_teste-lv_teste
 /dev/mapper/vg_teste-lv_teste: UUID="fe556bcb-879a-4537-92cd-2d40519089df" TYPE="ext4"

 

Criar um diretório onde iremos montar este volume:

[root@localhost ~]# mkdir /teste

 

E adicionar uma linha ao final do /etc/fstab com o id do volume, diretório e demais parâmetros necessários:

[root@localhost ~]# echo "UUID=fe556bcb-879a-4537-92cd-2d40519089df /teste ext4 defaults 0 0" >> /etc/fstab

 

Montamos todos os dispositivos contidos no /etc/fstab:

[root@localhost ~]# mount -a

 

E por fim verificamos se está tudo OK.

[root@localhost ~]# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda2             19306788   2809160  15516892  16% /
tmpfs                   515428        88    515340   1% /dev/shm
/dev/sda1               297485     31238    250887  12% /boot
/dev/mapper/vg_teste-lv_teste
10317112    154100   9638932   2% /teste

 

Pronto, nosso volume lógico “lv_teste”, contido no volume group “vg_teste”, identificado como “/dev/mapper/vg_teste-lv_teste” foi montado no diretório “/teste”.

No dia a dia, não precisamos executar alguns dos comandos citados neste post. Estes foram citados para facilitar a visualização do processo. Um fluxo resumido para obter o mesmo resultado seria executar os comandos “fdisk”, “pvcreate”, “vgcreate”, “lvcreate”, “mkfs.ext4”, “mkdir” e “mount” com os respectivos parâmetros.

Para um computador pessoal, onde não há muita “movimentação” de discos, não é obrigatório utilizar volumes de disco.

A clara vantagem de se utilizar volumes de disco será vista num próximo post onde irei mostrar como adicionar um segundo disco num volume já existente (o que criamos aqui) e somar suas capacidades fazendo o sistema operacional “enxergar” como se fosse um único disco maior.

Script para ntp fake (AKA como atualizar horário via http usando shell script)

Disclaimer:

O conteúdo deste post é histórico, mantido aqui apenas para ter exemplificar como fazer um script parsear um HTML. Para funcionar, ele depende de uma URL que não está mais disponível.
Atualmente (consultei em 31/05/2020), o Observatório Nacional disponibiliza na URL http://www.horalegalbrasil.mct.on.br/RelogioServidor.php a data em formato “epoch” que, basicamente, são quantos segundos se passaram desde a meia noite do dia 01/01/1970. Então basta converter esse número com o comando date para saber a hora atual.

Para ter uma ideia para um script, pode-se pensar em algo como:

$ date --date=@`curl -s http://www.horalegalbrasil.mct.on.br/RelogioServidor.php`

Sun May 31 18:43:43 -03 2020

E então pode-se seguir uma lógica semelhante ao que tem no restante do post se quiser que esta hora seja aplicada ao sistema.

Agradeço ao Ricardo, da Amplus, por ter informado que a URL do texto não estava mais ativa e ainda por ter sugerido essa nova URL citada acima.

Resumo da história:

Preciso que uma máquina virtual tenha a hora sempre correta mas não posso instalar o vmware tools e nem usar ntp para isso. Como fazer?

A história completa:

Tenho uma máquina virtual onde não consigo instalar o vmware-tools (máquina extremamente customizada, quase nada funciona ali sem muita modificação). Esta máquina virtual está numa rede onde não tem um servidor ntp e, para “ajudar”, o firewall desta rede não permite que eu acesse nenhum servidor ntp externo. Preciso que o horário nesta máquina esteja correto (ok, um ou outro segundo não é problema, mas a data estar na “semana passada” definitivamente não é bom).

Por sorte esta máquina consegue acessar http (via proxy, óbvio) então, tudo o que eu precisava era de uma página web que sempre tivesse a hora correta.

No Brasil, quem é o “responsável” pela hora oficial é o Observatório Nacional. Navegando pelo site deles encontrei uma url que tem a hora legal brasileira e é atualizada a cada segundo.

No meio daquela página vai ter a hora assim: 20/3/2012 15:45:38. Mas o comando date espera receber esta hora assim: 032015452012.38 (se lê de dois em dois dígitos, exceto o ano: mês; dia; hora; minuto; ano; “.” e segundo).

Então basicamente o que eu precisei é “ler” a página e “traduzir” para o formato que o comando “date” do Linux entende.

A gambiarra (AKA “solução” do problema):

Abri o source da página e tentei entender onde a data e hora estava. Vi que a hora que preciso aparece no meio de algumas tags html na terceira linha após o texto “Hora Oficial”.

O trecho do source em questão:

<TD ALIGN="CENTER" BGCOLOR=#E0FFFF><B>Hora Oficial de Brasília</B></TD>
</TR>
<TR>
<TD ALIGN="CENTER" BGCOLOR=#ffcc66><B>20/3/2012 15:45:38</B></TD>

Separei somente a linha que queria e “limpei” todas as tags, deixando somente a hora.

20/3/2012 15:45:38

Para o script ler a página, usei o comando curl, grep para procurar no texto por “Hora Oficial” e separar as próximas três linhas, tail para separar a última dessas três linhas e, finalmente, sed para remover as tags html.

O código usado (porco, confesso, mas pode rodar no seu shell) , é esse:

curl -s http://pcdsh01.on.br/HoraLegalBrasileira.asp|grep -A3 “Hora Oficial”|tail -1|sed ‘s/<TD ALIGN=”CENTER” BGCOLOR=#ffcc66><B>//g;s/<\/B><\/TD>//g’
 

Armazenei a saída desse comando numa variável, no caso “hora_full”.

Então traduzi a hora que ele me retornou para o formato do date (mais um código porco, mas está “didático”):

hora=`echo $hora_full|cut -d ” ” -f 2|cut -d : -f 1`
minuto=`echo $hora_full|cut -d ” ” -f 2|cut -d : -f 2`
segundo=`echo $hora_full|cut -d ” ” -f 2|cut -d : -f 3|tr -d ‘\r’`
mes=`echo $hora_full|cut -d “/” -f 2`
dia=`echo $hora_full|cut -d “/” -f 1`
ano=`echo $hora_full|cut -d “/” -f 3|cut -d ” ” -f 1`

E juntei tudo como parâmetro para o comando date:

date $mes$dia$hora$minuto$ano.$segundo

Se seu usuário tiver permissão para alterar a data do sistema, isto deverá “sincronizar” com o horário legal brasileiro.

PS: depois (AKA talvez um dia) eu coloque o script todo, inclusive com verificação se o usuário tem ou não permissão para acertar o horário do sistema.

Como configurar o yum para utilizar somente um repositório?

Como configurar o yum para utilizar somente um repositório?

Primeiro, o que gerou esta motivação?

Acompanho a lista fedora-users-br e vi este email do Ricardo Vendramini: http://lists.fedoraproject.org/pipermail/br-users/2010-November/013615.html

Para reduzir o uso de banda, surgiu a ideia de se configurar um proxy squid. Quando uma máquina for se atualizar, ela baixa os pacotes e o squid os armazena em cache. Quando uma segunda máquina buscar esta mesma atualização, o squid irá entregar o arquivo do cache ao invés de baixar novamente, economizando tempo (rede interna provavelmente é mais rápida que Internet) e banda.

O problema: o yum tem uma lista de mirrors possíveis e, a cada vez, ele pode utilizar um mirror diferente da última. Com isso, o squid terá diversas cópias de um mesmo arquivo mas vindo de domínios diferentes. Assim, além de não reduzir o uso da banda (ideia inicial) ainda se ocupa espaço de disco do cache que poderia ser melhor utilizado com outros arquivos.

Solução? “Forçar” o yum a baixar sempre de um mesmo mirror.
Para isso, deve-se configurar os repositórios “updates” e “fedora” (assim tanto os updates como eventuais instalações de pacotes serão armazenados no cache do squid). Então, edite o arquivo “/etc/yum.repos.d/fedora-updates.repo“, comente a linha “mirrorlist” e descomente “baseurl“. Em “baseurl“, coloque o endereço de um dos mirrors. Como sugestão, estou utilizando o mirror da Universidade Federal do Paraná que normalmente é bem rápido para usuários no Brasil.

[updates]
name=Fedora $releasever – $basearch – Updates
failovermethod=priority
baseurl=http://fedora.c3sl.ufpr.br/linux/updates//$releasever/$basearch/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

Também deve-se editar o “/etc/yum.repos.d/fedora.repo“:

[fedora]
name=Fedora $releasever – $basearch
failovermethod=priority
baseurl=http://fedora.c3sl.ufpr.br/linux/releases/$releasever/Everything/$basearch/os/
#mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=fedora-$releasever&arch=$basearch
enabled=1
metadata_expire=7d
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

Repita o procedimento em todas as máquinas com Fedora na rede. Feito isto, basta utilizar novamente o comando “yum update” para que todas as instalações e atualizações venham sempre do mesmo mirror.

Outra ideia para melhorar o desempenho, desabilitar o uso do plugin “yum-presto”. O presto utiliza o conceito de deltarpm para reduzir o tamanho dos pacotes de atualização. O deltarpm é um diff binário entre duas versões de rpm. Basicamente você baixa somente a diferença entre duas versões de um mesmo pacote e não mais o pacote todo. Ex: é liberada uma atualização do OpenOffice onde apenas um arquivo foi modificado. Este arquivo tem 1 Mbyte enquanto o pacote todo tem 50. O deltarpm teria aproximadamente 1 Mbyte e se teria uma economia de 49 Mbytes de download. Veja um outro artigo que escrevi sobre o yum presto aqui.

Mas como desabilitar o yum-presto melhora o desempenho? Como você terá todos os pacotes (ou pelo menos os mais utilizados) no cache do squid, você não estará fazendo o download de um pacote grande, você estará utilizando uma cópia localizada no cache na rede interna. Assim, o download será rápido e não precisará de tempo para reconstruir os pacotes de atualização, o que normalmente leva alguns minutos. Só para reforçar, yum-presto economiza muito download, mas aumenta o tempo de atualização devido a reconstrução do pacote. Se o tempo de download é muito baixo (rede interna), provavelmente não compensa o tempo de reconstrução, por isso a sugestão de desabilitar o yum-presto.

E como fazer isso? Basta editar o arquivo “/etc/yum/pluginconf.d/presto.conf” e configurar “enabled=0“. Pronto, da próxima vez que utilizar o yum, o plugin presto não será carregado.

Lançada a quinta edição da Revista Fedora Brasil

É com enorme prazer que o Projeto Fedora Brasil anuncia que já está disponível para download a 5ª edição da Revista Fedora Brasil.

Neste número fizemos uma abordagem especial à suite de escritórios BrOffice.org e fomos brindados com um editorial escrito pelo Gustavo Pacheco, sócio-fundador do BrOffice.org. Aproveitamos o ensejo para iniciar a série sobre BrOffice.org para uso avançado, então, se você quer saber todo o potencial do BrOffice.org este é um bom momento para começar a sua coleção.

Como sempre, escolhemos um jogo muito interessante: Secret Maryo Chronicles é um remake bastante especial de um jogo clássico que todo mundo conhece e com certeza vai agradar até mesmo aos jogadores mais exigentes.

Nem GNOME nem KDE, nós o convidamos a conhecer o Enlightenment, que promete transformar seu desktop numa obra de arte e, de quebra, fomos conversar com o Professor Gregory Kriehn, do departamento de engenharia da Universidade do Estado da Califórnia – e pai do repositório Enlightenment para Fedora.

Igor Soares analisa de forma clara a complexa situação dos drivers proprietários no mundo Linux e as aulas de Shell Script finalmente deixam a fase introdutória, agora sob a pena de Fabiano Caixeta Duarte. Tem mais: segurança com SPA, controle de banda, Conexões 3G e Yumex.

Faltou algo? Que tal a estreia das nossas tirinhas de humor?

Faça seu download: http://www.projetofedora.org/Revista

Fonte: Projeto Fedora

Fedora 11 Preview disponível para download

O Projeto Fedora disponibilizou para download a versão Preview do Fedora 11 – Leonidas.

Baixe, teste e reporte os erros encontrados! Contribua para que o Fedora 11 seja ainda mais estável e amigável aos nossos usuários.

O Fedora 11 Preview está disponível em LiveCDs, Cds de Instalacão e DVD.

Torrents: http://torrent.fedoraproject.org/

Novidades da versão: http://fedoraproject.org/wiki/Releases/11/FeatureList

Fonte: http://www.projetofedora.org/fedora11_preview_release

Lançada a quarta edição da Revista Fedora Brasil

Foi lançada hoje a quarta edição da Revista Fedora Brasil.

Segue anúncio oficial:

Para encerrar com chave de ouro o ano de 2008 o Projeto Fedora tem o prazer de anunciar o lançamento da quarta edição da Revista Fedora Brasil. Este número traz o editorial assinado por Augusto Campos, que traça uma retrospectiva sobre os 5 anos de existência do Fedora e mostra um quadro de como o ecossistema das distribuições Linux mudou após o anúncio do lançamento do primeiro Fedora. Além disso a revista também traz um enfoque especial ao novo Fedora 10, apresentando de maneira muito clara e simples todas as novidades e mudanças da nova release. Aproveite também para participar da promoção da Revista Fedora Brasil e concorra a um exemplar do livro “Java – Fundamentos, prática & certificação” do autor Adilson Bonanovisk.

Continuam as aulas sobre shell script, há também um passeio sobre os mistérios do SELinux, tiros certeiros no jogo Urban Terror e uma receita infalível para você fazer o seu próprio Fedora. Tem mais, muito mais, são 66 páginas onde a variedade não será problema.

Um feliz ano novo e não se esqueça de baixar a revista no link abaixo:

http://www.projetofedora.org/Revista

Projeto Fedora Brasil está levantando doações para compra de duplicadora e impressora de mídias

Visando a difusão do Fedora e a expansão da quantidade de mídias distribuídas a cada versão do Fedora em território nacional, o Projeto Fedora Brasil criou esta campanha de doação para a compra de uma impressora e duplicadora de CDs/DVDs.

Esta impressora/duplicadora será utilizada para gravação e impressão de mídias que serão distribuídas em eventos, grupos regionais e para aquelas pessoas que desejam instalar/testar o Fedora e não têm acesso a banda larga.

Para mais informações, acesse http://www.projetofedora.org/node/79