Roxy's questions

Eu estava procurando configurar uma pequena instalação de servidor e fiz a instalação mínima do Debian 9.6 que o instalador me permitiu fazer.

Esta instalação tem coisas como Python2, Python3, Perl, bluetooth, Wi-Fi, curl, wget e muito mais.

Não estou interessado em debater se estes devem ser parte de uma instalação mínima.

Em vez disso, quais partes da instalação básica do Debian requerem o uso destes? por exemplo, o que requer Python2 na instalação base? O que requer Python3 na instalação base? O que requer bluetooth? Como faço para descobrir isso?

Estou tentando entender a diferença de comportamento entre as ACLs do FreeBSD e as ACLs do Linux. Em particular, o mecanismo de herança para as ACLs padrão.

Eu usei o seguinte no Debian 9.6 e no FreeBSD 12:

$ cat test_acl.sh
#!/bin/sh

set -xe

mkdir storage
setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage

touch outside
cd storage
touch inside
cd ..

ls -ld outside storage storage/inside

getfacl -d storage
getfacl storage
getfacl outside
getfacl storage/inside

umask

Eu recebo a seguinte saída do Debian 9.6:

$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r--  1 aaa aaa    0 Dec 28 11:16 outside
drwxr-xr-x+ 2 aaa aaa 4096 Dec 28 11:16 storage
-rw-rw----+ 1 aaa aaa    0 Dec 28 11:16 storage/inside

+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---

+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::---

+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--

+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx          #effective:rw-
mask::rw-
other::---

+ umask
0022

Observe que os arquivos outsidee insidetêm permissões diferentes. Em particular, o outsidearquivo tem -rw-r--r--, que é o padrão para este usuário e o insidearquivo tem -rw-rw----, respeitando as ACLs padrão que atribuí ao storagediretório.

A saída do mesmo script no FreeBSD 12:

$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r--  1 aaa  aaa    0 Dec 28 03:16 outside
drwxr-xr-x  2 aaa  aaa  512 Dec 28 03:16 storage
-rw-r-----+ 1 aaa  aaa    0 Dec 28 03:16 storage/inside

+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---

+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x

+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--

+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx      # effective: r--
mask::r--
other::---

+ umask
0022

(Observe que o Debian getfacltambém mostrará as ACLs padrão mesmo quando não estiver usando -dwhere, pois o FreeBSD não, mas não acho que as ACLs reais storagesejam diferentes.)

Aqui, os arquivos outsidee também têm permissões diferentes, mas o arquivo não tem a permissão de escrita de grupo que a versão Debian tem, provavelmente porque a máscara no Debian reteve a máscara no FreeBSD perdeu o .insideinsideww

Por que o FreeBSD perdeu a wmáscara, mas o Debian a manteve?

Estou tentando escrever um script que irá descompactar e reempacotar um ISO do FreeBSD para que eu possa fazer uma instalação com ele. O objetivo é uma instalação autônoma.

Eu tenho o seguinte script escrito, mas não funciona. Enquanto o ISO original inicializará no VirtualBox no modo UEFI, o ISO recém-criado não.

#!/bin/sh

inst_cfg="$1"
src_iso="$2"
dst_iso="$3"

iso_mnt=$(mktemp -d /tmp/freebsd-mnt-XXXXXX)
iso_wrk=$(mktemp -d /tmp/freebsd-wrk-XXXXXX)

vol_id=$(isoinfo -d -i "${src_iso}" | sed -n -e 's/^Volume id: \(.*\)$/\1/p')

md_name=$(mdconfig -a -t vnode -f "${src_iso}")
mount -t cd9660 "/dev/${md_name}" "${iso_mnt}"

cp -a -v "${iso_mnt}/" "${iso_wrk}"
cp "${inst_cfg}" "${iso_wrk}/etc/installerconfig"
mkisofs -J -R -no-emul-boot -V "${vol_id}" -b boot/cdboot -o "${dst_iso}" "${iso_wrk}"

umount "${iso_mnt}" # cd9660
mdconfig -d -u "${md_name}"

rm -rf "${iso_mnt}"
rm -rf "${iso_wrk}"

O sistema de arquivos criado parece bom. Eu diferenciei os arquivos dos ISOs originais e personalizados e as únicas diferenças são o installerconfigarquivo adicionado e boot.catalog(o que eu entendo mkisofsacrescenta, mas por quê? Poderia ser esse o problema?)

Eu tentei várias combinações de opções para mkisofs, incluindo -R -U, -L -D -R, -J -R, mas nada faz diferença.

Além disso, o Manual do FreeBSD curiosamente tem o seguinte comentário:

Portanto, se /tmp/myboot contém um sistema FreeBSD inicializável com a imagem de inicialização em /tmp/myboot/boot/cdboot, este comando produziria /tmp/bootable.iso:

mkisofs -R -no-emul-boot -b boot/cdboot -o /tmp/bootable.iso /tmp/myboot

Isso não produz um ISO que inicializa no VirtualBox no modo UEFI.

Alguém tem ideia do que está errado?

Estou em um sistema FreeBSD minimalista e preciso usar o editor vi embutido para editar arquivos. Para ser específico, isso não é vim, ou vim-tiny ou outra substituição. É o editor nvi "4BSD bug-for-bug compatível".

Funciona quase como esperado. A página man diz que control-T e control-D irão recuar/desindentar de acordo com shiftwidth. Control-T funciona, mas control-D não. Na verdade, ele insere o caractere ^D no arquivo.

Se eu colocar o vim no sistema, control-T e control-D funcionam conforme o esperado, então não é um problema do terminal interpretar mal a chave. O próprio Vi não está interpretando o controle-D.

Alguém se depara com isso? Uma solução? Usar o vim não é uma opção.