quinta-feira, 25 de agosto de 2016

APNG será suportado no Chrome

The GIF Is Dead. Long Live the GIF. (Popular Mechanics) (via OSNews)

GIF, uma antiguidade que resiste ao caixão. Em grande parte pela falta de consenso entre os navegadores — principalmente depois que o reinado do Internet Explorer começou a acabar. Sem amplo suporte, os concorrentes modernos do GIF não ganharam tração.

APNG (Animated PNG) é suportado faz tempo no motor Gecko (Firefox) e no Presto (Opera antigo). No ano passado, foi adicionado ao WebKit (Safari). A grande notícia é que será implementado também no Blink (Chrome, Opera novo):

Animated PNG - Chrome Platform Status

As discussões haviam parado, mas nos últimos meses recomeçaram e a previsão é de até o fim do ano estar pronto.

Uma vez no Chrome, seu uso tende a aumentar e o GIF poderá ser aposentado ao poucos.

quarta-feira, 24 de agosto de 2016

ACLs e XATTRs nos principais sistemas de arquivos Linux

EXT4 XFS
POSIX_ACL CONFIG_EXT4_FS_POSIX_ACL CONFIG_XFS_POSIX_ACL
XATTR CONFIG_EXT4_FS_XATTR[1] sempre habilitado
SECURITY CONFIG_EXT4_FS_SECURITY CONFIG_XFS_SECURITY[2]
OP. MOUNT desnecessárias[3] desnecessárias

Btrfs JFS
POSIX_ACL CONFIG_BTRFS_FS_POSIX_ACL CONFIG_JFS_POSIX_ACL
XATTR sempre habilitado sempre habilitado
SECURITY sempre habilitado CONFIG_JFS_SECURITY
OP. MOUNT desnecessárias desnecessárias

ReiserFS
POSIX_ACL CONFIG_REISERFS_FS_POSIX_ACL
XATTR CONFIG_REISERFS_FS_XATTR
SECURITY CONFIG_REISERFS_FS_SECURITY
OP. MOUNT acl,user_xattr

Legenda:

- POSIX_ACL: configuração requerida para habilitar ACLs.
- XATTR: configuração requerida para habilitar atributos extendidos (XATTRs).
- SECURITY: configuração requerida para permitir o uso de XATTRs por módulos LSM (SELinux, Smack, etc.).
- OP. MOUNT: opções de montagem requeridas para habilitar ACLs e XATTRs.

As configurações dos três primeiros itens são definidas na hora da compilação e são controladas pelos empacotadores das distribuições. São recursos básicos, habilitados em praticamente todo lugar.

Caso complicado: EXT2/3/4

Desde o kernel 2.6.33 é possível usar o driver ext4 para montar volumes EXT2 e EXT3 (CONFIG_EXT4_USE_FOR_EXT23). No 4.3, o driver ext3 foi removido; portanto, o ext4 é sempre usado em volumes EXT3 a partir dessa versão. O driver ext2 continua disponível e a configuração para usar o ext4 em volumes EXT2 foi renomeada para CONFIG_EXT4_USE_FOR_EXT2. Levando em conta que desde o 2.6.38 o driver ext4 aplica as opções acl,user_xattr por padrão, caso sua distribuição tenha um kernel minimamente recente e habilite CONFIG_EXT4_USE_FOR_EXT23 ou CONFIG_EXT4_USE_FOR_EXT2 (a maioria habilita[4]), sistemas EXT2 e EXT3 também sempre terão suporte a ACLs e XATTRs sem precisar mexer nas opções de montagem.

Desde muito tempo atrás (lá na pré-história do kernel 2.4), sistemas EXT permitem que algumas opções de montagem pré-definidas sejam salvas em seus superblocos, o que possibilita, na hora da criação do sistema de arquivos, ao mke2fs (e seus atalhos de conveniência mkfs.ext2, mkfs.ext3 e mkfs.ext4) as definir. O mesmo pode ser feito posteriormente através da opção -o da ferramenta tune2fs. São respeitadas pelos três drivers, ext2, ext3 e ext4. A partir da versão 1.42, o mke2fs cria sistemas de arquivos EXT2/3/4 com as opções acl,user_xattr salvas no superbloco por padrão (redundante[5] com o driver ext4 desde o kernel 2.6.38). Note que as opções noacl,nouser_xattr, usadas para desabilitar os recursos, não podem ser armazenadas no superbloco[6]. Precisam ser passadas ao mount (via -o) ou postas no fstab.

Considerando volumes EXT2/3/4 com defaults em fs_mntops (fstab):

ACLs e XATTRs
Kernel ≥ 2.6.38 com
CONFIG_EXT4_USE_FOR_EXT23 ou
CONFIG_EXT4_USE_FOR_EXT2
habilitados
Kernel ≥ 2.6.38 sem
CONFIG_EXT4_USE_FOR_EXT23 ou
CONFIG_EXT4_USE_FOR_EXT2
EXT4: habilitados
EXT3 (kernel ≥ 4.3): habilitados
EXT3 (kernel < 4.3) e EXT2: dependem
das opções salvas no superbloco[7]
Kernel < 2.6.38 dependem das opções salvas
no superbloco

Ou seja, com exceção do ReiserFS, que ainda requer opções de montagem, os principais sistemas de arquivos vêm de fábrica com ACLs e XATTRs habilitados por padrão em distribuições modernas.


[1] A partir do kernel 3.8, a opção não existe mais e o suporte é sempre habilitado.
[2] A partir do kernel 2.6.26, a opção não existe mais e o suporte é sempre habilitado.
[3] Desde o kernel 2.6.38.
[4] CentOS 7+, Debian 8+, Ubuntu 14.04+, Fedora, openSUSE, Arch.
[5] Mesmo depois de remover as opções do superbloco com tune2fs -o ^acl,^user_xattr <dispositivo> e remontá-lo, o sistema de arquivos continuará suportando ACLs e XATTRs.
[6] Desde o kernel 2.6.35 e e2fsprogs 1.41.13, opções de montagem arbitrárias podem ser armazenadas no superbloco com tune2fs -E mount_opts="opção1 opção2 ..." <dispositivo>. No entanto, são interpretadas apenas pelo driver ext4 e não servem para noacl,nouser_xattr.
[7] Ver com tune2fs -l <dispositivo>.

terça-feira, 16 de agosto de 2016

Novidades do FSArchiver 0.8.0


- Suporta FAT16/32. Adicionado levando em conta seu uso em sistemas UEFI, para o volume da partição ESP (EFI System Partition).

- XFSv5 é restaurado mantendo a configuração -i sparse de acordo com o sistema original (desde a versão 0.6.24).

- É possível especificar na linha de comando, na ação restfs, uuid= e label=, que permitem substituir os valores armazenados na imagem. Muito útil para XFSv5, pois possibilita restaurar o sistema de arquivos com um UUID aleatório sem precisar aumentar o kernel mínimo requerido rodando xfs_admin depois, pois o UUID será passado diretamente ao mkfs.xfs (≥ 4.3.0) na hora de criá-lo. Isso também evita incompatibilidade com o GRUB, que até recentemente não suportava meta_uuid.

- Btrfs é restaurado preservando o UUID da imagem. Detalhe: mkfs.btrfs falha se já existir um sistema de arquivos com UUID igual, contudo. Nesse caso, a saída é especificar um novo através da opção uuid=.

Excelente programa. O melhor para clonagem de sistemas de arquivos Linux.

Meu script foi atualizado.

domingo, 14 de agosto de 2016

Ainda é possível atualizar do Windows 8/8.1 para o 10

Semana passada, instalei o Windows 10 1607 (compilação 14393, vulgo Redstone 1) Single Language do zero em um notebook Dell que estava com o 8.1 (este havia sido atualizado do 8 de fábrica). Não foi uma atualização. Apaguei o particionamento com o diskpart antes. O instalador nem pediu chave, sinal de que detectou e aceitou a gravada no firmware. Ao final, estava ativado.

Ontem, tive a oportunidade de testar o mesmo processo, porém num tudo em um da CCE que ainda rodava o Windows 8. Inicialização através da mídia, particionamento apagado, instalação do zero: instalador não pediu chave e o sistema ativou sem soluçar.

Então, pelo menos em máquinas com chaves do 8 e 8.1 no firmware, ainda está sendo possível atualizar para o 10 (lembrando que oficialmente a gratuidade acabou em 29 de julho deste ano). Melhor ainda: diretamente via instalação limpa. Vamos ver por quanto tempo.

segunda-feira, 1 de agosto de 2016

Personalizando as páginas de erro do Squid

O daemon monta as páginas com base nos esqueletos presentes em /usr/share/squid/errors/<locale>/. São servidas de acordo com a língua do cliente obtida do cabeçalho HTTP. Do arquivo /etc/squid/errorpage.css sai o estilo. Seu conteúdo é injetado no HTML dentro de um elemento <style>.

Pacotes RPM marcam /etc/squid/errorpage.css como %config(noreplace): ao ser editado localmente, nunca é substituído por cópia mais recente do pacote (/etc/squid/errorpage.css.rpmnew será criado caso necessário). No que diz respeito à aparência, esse arquivo é território do administrador.

Imagens precisam ser hospedadas num servidor web acessível aos clientes.

Aparência padrão

Mexendo um pouquinho no CSS.

--- /etc/squid/errorpage.css    2017-02-06 09:20:07.000000000 -0200
+++ /etc/squid/errorpage.css    2017-02-10 13:52:05.462396002 -0200
@@ -21,9 +21,10 @@
 html body {
     margin: 0;
     padding: 0;
-    background: #efefef;
     font-size: 12px;
     color: #1e1e1e;
+    background: url('http://centos.localdomain/interestelar.jpg') center top/cover no-repeat fixed black;
+    text-shadow: 3px 3px 5px lightgrey;
 }
 
 /* Page displayed title area */
@@ -31,15 +32,15 @@
     margin-left: 15px;
     padding: 10px;
     padding-left: 100px;
-    background: url('/squid-internal-static/icons/SN.png') no-repeat left;
+    background: url('http://centos.localdomain/cafe.png') left/90px no-repeat;
 }
 
 /* initial title */
 #titles h1 {
-    color: #000000;
+    color: white;
 }
 #titles h2 {
-    color: #000000;
+    color: white;
 }
 
 /* special event: FTP success page titles */
@@ -52,6 +53,8 @@
 #content {
     padding: 10px;
     background: #ffffff;
+    opacity: 0.8;
+    text-shadow: none;
 }
 
 /* General text */
@@ -101,4 +104,5 @@
 #footer {
     font-size: 9px;
     padding-left: 10px;
+    color: white;
 }

Aplicamos com systemctl reload squid.service.

Resultado:

Interestelar

(imagem daqui)

Fica menos monótono para os clientes. ☺

[Atualização - 10/02/2017] Colocar background-size dentro de background.