Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pt.comp.so.linux > #2835 > unrolled thread

Como criar um sistema mínimo para systemd-nspawn com modo gráfico?

Back to article view | Back to pt.comp.so.linux

Contents

  Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-01 21:40 +0100
    Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-01 22:33 +0100
      Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-02 09:33 +0100
        Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-02 08:38 -0300
    Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-01 22:54 -0300
      Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-02 10:04 +0100
        Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-02 08:59 -0300
          Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-02 14:43 +0100
            Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-03 03:34 +0100
              Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-03 08:09 +0100
                Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-03 08:31 +0100
                  Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-03 06:16 -0300
                    Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-03 15:42 +0100
                      Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-03 17:04 -0300
                        Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-04 05:29 +0100
                          Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-04 09:02 +0100
                            Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-04 19:12 +0100
                        Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-04 08:58 +0100
                          Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-04 10:40 -0300
                    Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-03 15:53 +0100
                      Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-03 19:39 +0100
                        Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? João Jerónimo <jj.mailspam@yahoo.com> - 2020-07-15 10:19 +0100
                Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-03 19:37 +0100
                  Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-04 09:40 +0100
                    Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-04 19:25 +0100
                Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Paulo da Silva <p_d_a_s_i_l_v_a_ns@nonetnoaddress.pt> - 2020-07-05 08:08 +0100
              Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Patricia Ferreira <pferreira@example.com> - 2020-07-03 05:56 -0300
    Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? João Jerónimo <jj.mailspam@yahoo.com> - 2020-07-13 12:16 +0100
      Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? Ninguém <usenet@rasparta.org> - 2020-07-15 10:31 +0100
        Re: Como criar um sistema mínimo para systemd-nspawn com modo gráfico? João Jerónimo <jj.mailspam@yahoo.com> - 2020-07-17 12:01 +0100

Page 1 of 2  [1] 2  Next page →

#2835 — Como criar um sistema mínimo para systemd-nspawn com modo gráfico?

Eu tenho feito assim:
Com debootstrap instalo uma versão mínima do debian numa diretoria e 
depois consigo arrancá-la com systemd-nspawn.

Mas não sei como fazer algumas coisas:
- Como configurar vários sistemas semelhantes e ligá-los todos como se 
estivessem ligados a um switch virtual (como se fosse um laboratório 
virtual, com uma rede diferenciada)?
Presumo que tenha que configurar uma placa de rede virtual... mas e 
depois não há o perigo de os sistemas "virtuais" "verem" o sistema real? 
Não queria isso!
- Como fazer para que tenha um ambiente gráfico (wayland) e que, ao 
arrancar, me arranque numa janela à semelhança do virtualbox?
- Como configurar os cgroups de forma a proteger ao máximo o sistema 
anfitrião?

Penso que o qubes faz algo semelhante, mas recorre ao xen ou ao kvm... 
eu pretendia algo mais ligeiro.

[toc] | [next] | [standalone]

#2837

Às 21:40 de 01/07/20, Ninguém escreveu:
> Eu tenho feito assim:
> Com debootstrap instalo uma versão mínima do debian numa diretoria e
> depois consigo arrancá-la com systemd-nspawn.
> 
Para quem não é informático ... sabes umas coisas ;-)
Nem conhecia isto ...

...

> - Como fazer para que tenha um ambiente gráfico (wayland) e que, ao
> arrancar, me arranque numa janela à semelhança do virtualbox?
Há uns tempos - estou a ficar velho - eu arrancava qualquer aplicação
gráfica na própria sessão ou noutra. Isso, subitamente, deixou de funcionar.

Por ex., para arrancar com uma nova sessão do KDE noutro DISPLAY mesmo
dum PC remoto fazia o seguinte comando:

X :1 & sleep 5 ; xterm -display :1 -e ssh -XC <servidor> startkde &

Isto tinha várias variantes. Obrigava a uma alteração qq. em /etc nos
Debians like - tenho anotado algures - mas agora nada funciona :-( .
Em vez do X podia-se, por ex., usar o Xnest para uma janela da própria
sessão. - ainda existe o pacote xnest. Talvez queiras explorá-lo.

Por ex. para arrancar uma nova sessão com outro user no meu PC, tenho de
ir a uma consola "real" (não sei porque não funciona nas outras), fazer
login como outro user, e lançar startx -- :1.

Se tentar na GUI do KDE (Nova sessão), não dá em paralelo! O tipo "mata"
a sessão corrente. Não acontecia na versão anterior.

...

> 
> Penso que o qubes faz algo semelhante, mas recorre ao xen ou ao kvm...
> eu pretendia algo mais ligeiro.
Gosto do qubes. Só não o uso porque necessito da gráfica para "fazer
contas" e ele não faz passthrough. Há uns hacks, mas não parecem
funcionar muito bem.

Cumps.

[toc] | [prev] | [next] | [standalone]

#2839

Obrigado,

Mas tudo isso é com o Xorg.
Também costumava usar o xnest, aliás, foi à procura pelos termos "xnest" 
e "wayland" que descobri como fazer o mesmo no wayland. Agora não me 
lembro como é... penso que é só arrancar o weston... com "--nested"? Já 
não sei.

Estamos todos a ficar velhos (o universo funciona assim, não há volta a 
dar-lhe) :-) , mas eu também vou perdendo o pé cada vez mais.
Esta cena de systemd e wayland... tenho que reaprender uma data de coisas!

[toc] | [prev] | [next] | [standalone]

#2841

Ninguém <usenet@rasparta.org> writes:

[...]

> Estamos todos a ficar velhos (o universo funciona assim, não há volta
> a dar-lhe) :-) 

Será que não? :-)

> , mas eu também vou perdendo o pé cada vez mais.  Esta cena de systemd
> e wayland... tenho que reaprender uma data de coisas!

Conversávamos há poucos threads sobre isso.  Podemos passar a vida
reaprendendo a usar software ou podemos manter um conjunto razoável pela
vida inteira pra não ter que ficar reaprendendo, recriando uma caixa de
ferramentas.

[toc] | [prev] | [next] | [standalone]

#2838

Ninguém <usenet@rasparta.org> writes:

> Eu tenho feito assim:
> Com debootstrap instalo uma versão mínima do debian numa diretoria e
> depois consigo arrancá-la com systemd-nspawn.

Por que você faz isso?  Qual o problema que se resolve com essa solução?

> Mas não sei como fazer algumas coisas:
> - Como configurar vários sistemas semelhantes e ligá-los todos como se
> estivessem ligados a um switch virtual (como se fosse um laboratório
> virtual, com uma rede diferenciada)?

O debootstrap parece automatizar uma série de operações num certo
diretório (como baixar vários pacotes pra dentro desse diretório) e
termina lhe concedendo um shell dentro desse diretório logo depois de
alterar a raiz do processo do shell pra apontar pra esse diretório.  O
efeito é um shell que não consegue escapar desse diretório.  É por isso
que você tem a solução de que está num novo sistema, mas é só um
diretório no seu velho sistema.

Pra você compreender o debootstrap, é educacional que você estude o
chroot isoladamente.  Obtenha um shell S estático (isto é, não
dinamicamente montável pra que ele possa ser executado sem requerer
qualquer biblioteca), crie um diretório novo d/ e coloque S dentro de
d/.  Em seguida, peça ao super usuário pra fazer um chroot em d/ e
executar o shell que você colocou lá.  Assim:

%file /bin/sh
/bin/sh: ELF 32-bit LSB executable, Intel 80386, version 1, for OpenBSD,
statically linked, stripped

Note que o shell é estático.

%mkdir d
%cp /bin/sh d/

Criei d e coloquei o shell estático em d/sh.

%sudo chroot d/ /sh
/sh: No controlling tty (open /dev/tty: No such file or directory)
/sh: warning: won't have full job control
#

O shell não encontra o /dev/tty.  Claro, não existe esse arquivo ali.
Tem apenas o sh lá dentro.  Onde estou?

# pwd
/

Na raiz.  É isso que o chroot faz.  It [ch]anges the ]root] of the file
system --- e em seguida executa um processo.  Note que nem conseguimos
listar arquivos usando esse shell porque não um ls.

# ls
/sh: ls: not found

A alternativa é usar a capacidade do próprio shell de ler um diretório.
Podemos usar a expansão de expressões regulares, uma solução útil quando
o ls não está por perto pra ajudar.

# echo *
sh
#

> Presumo que tenha que configurar uma placa de rede virtual... mas e
> depois não há o perigo de os sistemas "virtuais" "verem" o sistema
> real? Não queria isso!  - Como fazer para que tenha um ambiente
> gráfico (wayland) e que, ao arrancar, me arranque numa janela à
> semelhança do virtualbox?  - Como configurar os cgroups de forma a
> proteger ao máximo o sistema anfitrião?

Você parece estar em busca de uma solução como o Docker.  Um kernel como
o Linux primeiro permitiu que você alterasse a raiz do sistema de
arquivos em cada processo.  É o que permite o chroot.  Depois eles
implementaram o que é chamado hoje de namespaces.  Um sistema de
arquivos é um namespace.  Você parece interessado em compreender o que é
um namespace e o Docker seria a solução que você busca.  (Já que você
não está interessado num isolamento total como os providos por um
virtualizador.)  O Docker vai lhe dar a sensação de que você está de
fato isolado num sistema novo, mas é nada mais que a ilusão do chroot
porque seus processos estarão todos sendo executados pelo seu próprio
sistema.

> Penso que o qubes faz algo semelhante, mas recorre ao xen ou ao
> kvm... eu pretendia algo mais ligeiro.

Xen e KVM funcionam são hypervisors.  Uma forma mais eficiente de se
executar máquinas virtuais.  Pela descrição que você faz, o Docker
parece ser o que mais se adapta a sua necessidade.

[toc] | [prev] | [next] | [standalone]

#2840

É quase isso, Patrícia.

O chroot era a solução que eu usava antes, mas o systemd-nspawn 
parece-me melhor (chroot on steroids).
Eu preciso do sistema completo (apesar de minimal) dentro desse chroot 
porque a intenção é usar para testar configurações e fazer experiências. 
Apenas a shell não basta - posso, num sistema destes, por exemplo, 
dispensar as manpages, mas não o sistema apt.

Eu devia ter explicado para que quero este "setup" - basicamente como se 
fosse um laboratório virtual:
- Experimentar com configurações antes de implementar no meu sistema de 
utilização diária;
- Poder, facilmente, mandar um computador para o lixo >:) sem perder 
grande coisa;
- Experimentar software antes de instalar no sistema a sério;
- Isolar, por questões de segurança (eu sei que não é perfeito), algum 
software menos confiável do sistema principal.
- Instalar e usar software de que preciso apenas momentaneamente e que 
depois posso "mandar para o lixo".

Na prática, eu devo estar a reimplementar o docker, sim. Mas queria 
evitar instalar mais software para coordenar um setup relativamente 
simples. Systemd-nspawn parece-me perfeito.
Também andei a ver lxc e outros... acabei por me decidir pelo 
Systemd-nspawn.
Os hipervisors são "overkill" para aquilo que eu quero. Só se vier a 
utilizar outro computador físico para testar coisas realmente mais 
perigosas, que, para já, não é o meu interesse.

[toc] | [prev] | [next] | [standalone]

#2842

Ninguém <usenet@rasparta.org> writes:

> É quase isso, Patrícia.

Não recomendava o chroot pra você usar.  Mencionei o chroot pra explicar
porque o debootstrap não lhe serve como desejas.  Você quer mais do que
um chroot.  O debootstrap lhe oferece apenas um chroot.

> O chroot era a solução que eu usava antes, mas o systemd-nspawn
> parece-me melhor (chroot on steroids).

Conversávamos há poucos threads sobre passar a vida reaprendendo a usar
software.  O systemd é um excelente exemplo de reinventar a roda sem
adicionar nada realmente novo ou valioso.  Você está reaprendendo a usar
um novo sistema sem necessidade.

> Eu preciso do sistema completo (apesar de minimal) dentro desse chroot
> porque a intenção é usar para testar configurações e fazer
> experiências. Apenas a shell não basta - posso, num sistema destes,
> por exemplo, dispensar as manpages, mas não o sistema apt.

O chroot não lhe limitada em nada em termos de que programas você pode
rodar ou a que arquivos você teria acesso.  (O debootstrap usa um chroot
pra fazer seu trabalho.)

> Eu devia ter explicado para que quero este "setup" - basicamente como
> se fosse um laboratório virtual:
> - Experimentar com configurações antes de implementar no meu sistema
> de utilização diária;
> - Poder, facilmente, mandar um computador para o lixo >:) sem perder
> grande coisa;
> - Experimentar software antes de instalar no sistema a sério;
> - Isolar, por questões de segurança (eu sei que não é perfeito), algum
> software menos confiável do sistema principal.
> - Instalar e usar software de que preciso apenas momentaneamente e que
> depois posso "mandar para o lixo".
>
> Na prática, eu devo estar a reimplementar o docker, sim. Mas queria
> evitar instalar mais software para coordenar um setup relativamente
> simples. Systemd-nspawn parece-me perfeito.
> Também andei a ver lxc e outros... acabei por me decidir pelo
> Systemd-nspawn.
> Os hipervisors são "overkill" para aquilo que eu quero. Só se vier a
> utilizar outro computador físico para testar coisas realmente mais
> perigosas, que, para já, não é o meu interesse.

No seu lugar, usaria um virtualizador.  Exatamente pra você ter a
liberdade que você não tem hoje e a garantia de playground seguro.  Você
não precisa de velocidade ou espaço folgado para fazer alguns testes.  A
máquina virtual pode rodar apenas quando você precisa.  O que você
realmente precisa é de conveniência --- criar e destruir máquinas
virtuais rapidamente, o que você não consegue sem uma solução para o
problema (1), sobre o qual conversamos.  Com um virtualizador,
entretanto, você cria uma máquina virtual e usa-a como modelo sempre:
instalar um sistema se resume a clonar essa máquina modelo.

[toc] | [prev] | [next] | [standalone]

#2843

Continuo a preferir o sistema debootstrap + systemd-nspawn.
Obrigado ;-)

[toc] | [prev] | [next] | [standalone]

#2844

Às 14:43 de 02/07/20, Ninguém escreveu:
> Continuo a preferir o sistema debootstrap + systemd-nspawn.
> Obrigado ;-)
> 
Agora fiquei com curiosidade ...
Podes postar um exemplo de comandos "get started" só para ter uma ideia.
Vi no pacote "Inicializa um sistema debian básico". A partir de quê?

Obrigado

[toc] | [prev] | [next] | [standalone]

#2845

On 03/07/20 03:34, Paulo da Silva wrote:
> Agora fiquei com curiosidade ...
> Podes postar um exemplo de comandos "get started" só para ter uma ideia.
> Vi no pacote "Inicializa um sistema debian básico". A partir de quê?

Posso.
Está aqui uma cópia de parte da minha documentação (revista e aumentada) 
que uso para instalar um sistema:

* debootstrap

Convém usar a última versão do debootstrap, que é apenas um shell 
script. À data não há problema em utilizar uma versão posterior à do 
repositório do sistema atual.

# git clone https://salsa.debian.org/installer-team/debootstrap.git
# export DEBOOTSTRAP_DIR=$(realpath debootstrap)

OBSERVAÇÃO: a utilização do git assegura que estamos a usar a última 
versão, mas há um pacote debootstrap que o instala no teu sistema, se 
quiseres, muito mais comodamente. Ficas com capacidade de, a partir de 
um sistema, instalares outro. Tenho isso num sistema que utilizo numa 
pen que trago no chaveiro.
Também tens de adaptar o export.
De volta à documentação...

Como em qualquer projeto, criar um ambiente próprio... neste caso, basta 
criar uma diretoria para trabalhar.
Criamos numa subdiretoria da nossa diretoria de trabalho...

# mkdir -p sistema

...e montamos lá a partição que vamos usar.

# mount /dev/sdx1 sistema

Nota: O passo seguinte pode ser acelerado, se os pacotes já estiverem na 
nossa rede.

OBSERVAÇÃO: Se não o configuraste de outra forma, o apt deixa-te os 
pacotes que instala no teu sistema em /var/cache/apt/archives, se forem 
os mesmos... (digo isto porque podes estar a instalar um sistema stable 
a partir de um testing, ou outra qualquer combinação).
Outra possibilidade é algum cache local.

Depois é só correr o comando:

# debootstrap/debootstrap stable sistema https://deb.debian.org/debian

Nota: Por alguma razão, o mirror português - 
http://ftp.pt.debian.org/debian - não funcionou!:

   E: Failed getting release file 
http://ftp.pt.debian.org/debian/dists/stable/Release

Nota: Se, por alguma razão, estiverem já disponíveis os pacotes .deb 
numa diretoria local - por ter sido realizada outra instalação 
recentemente, por exemplo - podem ser copiados para 
/var/cache/apt/archives/ que acelera a instalação. Não esquecer que esta 
diretoria tem uma subdiretoria "partial" e há que respeitar as permissões!
Utilizar o mirror mais conveniente.

# unset DEBOOTSTRAP_DIR

Fica instalado um sistema (não arrancável) na diretoria sistema e, por 
consequência, na partição /dev/sdx1.

* systemd-nspawn

Dar um nome ao sistema.

# echo sistema > sistema/etc/hostname

Criar a diretoria para, posteriormente, o utilizador ter a sua onde 
montar a partição de dados:

# chmod 701 sistema/srv
# mkdir -p sistema/srv/data -m 701

OBSERVAÇÃO: Eu não gosto daquela coisa de usar a mesma home em vários 
sistemas, ou exportar a home. Prefiro ter a home de cada sistema nesse 
mesmo sistema e ter uma diretoria, em cada sistema, onde cada utilizador 
tem uma diretoria sua onde pode colocar dados. Esta pode ser partilhada 
entre sistemas.
É por isso que ali em baixo vou referir uma partição /dev/sdx3.

O fstab!...

# echo "UUID=$(blkid -s UUID -o value /dev/sdx1) / ext4 
errors=remount-ro,relatime 0 1" > sistema/etc/fstab
# echo "UUID=$(blkid -s UUID -o value /dev/sdx3) /srv/data ext4 
errors=remount-ro,relatime 0 2" >> sistema/etc/fstab
# echo "UUID=$(blkid -s UUID -o value /dev/sdx4) none swap defaults 0 0" 
 >> sistema/etc/fstab

Alterar a password do root no novo sistema.

OBSERVAÇÃO: Aqui acho que deu erro da vez passada. Tenho que rever. Se 
não der, utiliza chroot em vez de systemd-nspawn.

# systemd-nspawn --directory=sistema passwd

Agora correr o sistema "contido" com systemd-nspawn.

# systemd-nspawn --boot --bind=/dev/sdx --bind=/dev/sdx1 
--bind=/dev/sdx3 --directory=sistema

Ou, mais fácil: # systemd-nspawn -bD sistema --bind=/dev/sdx 
--bind=/dev/sdx1 --bind=/dev/sdx3

Boas brincadeiras.
Qualquer observação, já sabem...

[toc] | [prev] | [next] | [standalone]

#2846

Repara que o sistema não é "arrancável": falta um kernel, tratar do 
bootloader... acho que tens que instalar o locales, o dbus costumava ser 
necessário por causa do systemd-nspawn...
Tudo isso se resolve facilmente quando arrancas o sistema com o 
systemd-nspawn - lá dentro usas o apt e instalas o que queres.
Há formas de o debootstrap instalar logo outro software que saibas que 
precisas. Dá uma olhada no man.

Olha eu a dizer RTFM ao Paulo! :-D

[toc] | [prev] | [next] | [standalone]

#2848

Ninguém <usenet@rasparta.org> writes:

> Repara que o sistema não é "arrancável": falta um kernel, tratar do
> bootloader... acho que tens que instalar o locales, o dbus costumava
> ser necessário por causa do systemd-nspawn...

Senhor, desculpe-me a ousadia de lhe dizer que parece a mim que você não
compreende exatamente o que faz o systemd-nspawn.  É uma ousadia
tremenda porque eu mesma nunca o executei. :-)

Não há como iniciar dois kernels num mesmo sistema UNIX, então não há
que se falar em ``falta[r] um kernel''.  O que o systemd-nspawn pode
fazer é rodar um processo com PID 1 dentro de um novo namespace.

Talvez fosse interessante você compreender exatamente o que é um
namespace.  Qual é a resposta para a pergunta --- o que é um namespace?

[...]

> Olha eu a dizer RTFM ao Paulo! :-D

O senhor é ousado também. :-D

[toc] | [prev] | [next] | [standalone]

#2849

On 03/07/20 10:16, Patricia Ferreira wrote:
> Senhor, desculpe-me a ousadia de lhe dizer que parece a mim que você não
> compreende exatamente o que faz o systemd-nspawn.  É uma ousadia
> tremenda porque eu mesma nunca o executei.:-)

Não faz mal nenhum. Eu nunca comi jaca, mas, se me oferecer, sei como comer.

> Não há como iniciar dois kernels num mesmo sistema UNIX, então não há
> que se falar em ``falta[r] um kernel''.  O que o systemd-nspawn pode
> fazer é rodar um processo com PID 1 dentro de um novo namespace.

Sim é isso.
Quando eu disse que não era "arrancável" queria dizer que não dá para 
inciar o sistema no "bare metal" por falta do kernel e, eventualmente, 
do bootloader (penso que o pessoal entendeu).
É "arrancável" com o systemd-nspawn que não é um "arranque" verdadeiro, 
é apenas a inicialização dos serviços do sistema num ambiente próprio (a 
partir do tal pid 1).

> Talvez fosse interessante você compreender exatamente o que é um
> namespace.  Qual é a resposta para a pergunta --- o que é um namespace?

Queres elaborar? Podes partir do princípio que entendo o namespace como 
a "árvore" do DNS, por exemplo, mas, de facto, nunca precisei de 
verbalizar o que entendo pelo conceito.

[toc] | [prev] | [next] | [standalone]

#2853

Ninguém <usenet@rasparta.org> writes:

> On 03/07/20 10:16, Patricia Ferreira wrote:
>> Senhor, desculpe-me a ousadia de lhe dizer que parece a mim que você não
>> compreende exatamente o que faz o systemd-nspawn.  É uma ousadia
>> tremenda porque eu mesma nunca o executei.:-)
>
> Não faz mal nenhum. Eu nunca comi jaca, mas, se me oferecer, sei como comer.

LOL!  Bem colocado.

>> Não há como iniciar dois kernels num mesmo sistema UNIX, então não há
>> que se falar em ``falta[r] um kernel''.  O que o systemd-nspawn pode
>> fazer é rodar um processo com PID 1 dentro de um novo namespace.
>
> Sim é isso.
> Quando eu disse que não era "arrancável" queria dizer que não dá para
> inciar o sistema no "bare metal" por falta do kernel e, eventualmente,
> do bootloader (penso que o pessoal entendeu).

Agora entendo.

> É "arrancável" com o systemd-nspawn que não é um "arranque"
> verdadeiro, é apenas a inicialização dos serviços do sistema num
> ambiente próprio (a partir do tal pid 1).

Isso é um arranque verdadeiro. :-) O que o init faz é essencialmente
executar outros programas.  Não existe nada de especial no init, exceto
ser o único a possuir o PID 1 --- dentro de seu namespace.  (Essa
qualificação final relativa a namespaces hoje se faz necessária devido à
introdução de namespaces relativos à árvore de processos.)

>> Talvez fosse interessante você compreender exatamente o que é um
>> namespace.  Qual é a resposta para a pergunta --- o que é um namespace?
>
> Queres elaborar? Podes partir do princípio que entendo o namespace
> como a "árvore" do DNS, por exemplo, mas, de facto, nunca precisei de
> verbalizar o que entendo pelo conceito.

Bom exemplo.  DNS é por si só um namespace.  Um namespace, como o nome
sugere, é um conjunto de nomes relativos a objetos, sendo que esses
nomes identificam os objetos a que eles se referem.

(*) O sistema de arquivos implementa um namespace

Um sistema de arquivos, por exemplo, implementa um namespace.  O poema
de Camões, armazenado no sistema de arquivos, é identificado pelo nome

  /poemas/cam.txt

O nome 

  /poemas

identifica a diretoria ``poemas'', que se localiza na diretoria raiz do
sistema de arquivos.  

Quando você pede ao kernel pra aplicar um chroot a um determinado
processo P numa determinada diretoria como

  /jaula

o kernel faz com que P passe a enxergar a diretoria raiz / como sendo a
diretoria /jaula.  Isso efetivamente impede P de acessar qualquer
elemento do sistema de arquivos que esteja fora de /jaula.  Por exemplo,
P não consegue acessar /etc/passwd porque, para P, o arquivo /etc/passwd
é na verdade /jaula/etc/passwd, uma vez que ``/'' é na verdade
``/jaula''.

(*) Uma árvore de processos UNIX implementa um namespace

Note que ``processo'' é distinto de ``programa''.  Um programa é uma
sequência de instruções de máquina.  Um processo é uma instância desse
programa em memória.  Um processo possui um PID.  Um programa não.

Cada processo tem um PID.  Logo, cada PID identifica um processo.  Um
sistema sempre UNIX usa um processo de PID 1.  Só um processo pode ter o
PID 1.  Se por ventura você desejar rodar dois processos com PID 1, você
vai precisar de dois namespaces para processos.

No kernel Linux, só existe uma forma de criar processos: pedindo ao
sistema para duplicar o processo em execução, o que é feito pela chamada
do sistema de nome clone().  Ao invocar clone(), você tem a chance de
pedir por várias coisas.  Por exemplo, você pode pedir por

  CLONE_NEWPID

e então um novo ``PID namespace'' é criado para o novo processo que
clone produz.  (Se você não pede por CLONE_NEWPID, então o novo processo
criado vive no mesmo PID namespace que seu processo pai --- o processo
que invocou clone().)

Similar ao pedido CLONE_NEWPID, existe o pedido 

  CLONE_NEWNET,

o que lhe concede um novo namespace relativo à rede.  (Você poderia por
exemplo construir uma tabela de roteamento diferente da usada em seu
namespace original de rede.  Cabe notar que uma placa de rede, por
exemplo, só pode pertencer a um namespace de cada vez.  Se você quer
testar um programa de rede numa configuração de rede diferente da sua
atual, você precisaria, por exemplo, de uma interface de rede virtual.)

Similar a esses, existe o pedido 

  CLONE_NEWNS,

que lhe dá um novo namespace para o sistema de arquivos, o que te
permite por exemplo usar o nome /etc/passwd como o nome de um arquivo
completamente diferente do seu original.  

As vantagens de CLONE_NEWNS você já conhece bem.  Você anda interessado
em CLONE_NEWPID e CLONE_NEWNET.  A forma usuário-final típica de usar
esses recursos é pilotando um software como Docker ou concorrentes.
Tecnicamente, você pode escrever seu próprios programas e obter o mesmo
efeito ``si hablas un poco del lenguaje C, el lenguaje UNIX''.

[toc] | [prev] | [next] | [standalone]

#2854

Às 21:04 de 03/07/20, Patricia Ferreira escreveu:
> Ninguém <usenet@rasparta.org> writes:
> 
>> On 03/07/20 10:16, Patricia Ferreira wrote:
>>> Senhor, desculpe-me a ousadia de lhe dizer que parece a mim que você não
>>> compreende exatamente o que faz o systemd-nspawn.  É uma ousadia
>>> tremenda porque eu mesma nunca o executei.:-)
>>
>> Não faz mal nenhum. Eu nunca comi jaca, mas, se me oferecer, sei como comer.
> 
> LOL!  Bem colocado.
> 
>>> Não há como iniciar dois kernels num mesmo sistema UNIX, então não há
>>> que se falar em ``falta[r] um kernel''.  O que o systemd-nspawn pode
>>> fazer é rodar um processo com PID 1 dentro de um novo namespace.
>>
>> Sim é isso.
>> Quando eu disse que não era "arrancável" queria dizer que não dá para
>> inciar o sistema no "bare metal" por falta do kernel e, eventualmente,
>> do bootloader (penso que o pessoal entendeu).
> 
> Agora entendo.
> 
>> É "arrancável" com o systemd-nspawn que não é um "arranque"
>> verdadeiro, é apenas a inicialização dos serviços do sistema num
>> ambiente próprio (a partir do tal pid 1).
> 
> Isso é um arranque verdadeiro. :-) O que o init faz é essencialmente
> executar outros programas.  Não existe nada de especial no init, exceto
> ser o único a possuir o PID 1 --- dentro de seu namespace.  (Essa
> qualificação final relativa a namespaces hoje se faz necessária devido à
> introdução de namespaces relativos à árvore de processos.)
> 
>>> Talvez fosse interessante você compreender exatamente o que é um
>>> namespace.  Qual é a resposta para a pergunta --- o que é um namespace?
>>
>> Queres elaborar? Podes partir do princípio que entendo o namespace
>> como a "árvore" do DNS, por exemplo, mas, de facto, nunca precisei de
>> verbalizar o que entendo pelo conceito.
> 
> Bom exemplo.  DNS é por si só um namespace.  Um namespace, como o nome
> sugere, é um conjunto de nomes relativos a objetos, sendo que esses
> nomes identificam os objetos a que eles se referem.
> 
> (*) O sistema de arquivos implementa um namespace
> 
> Um sistema de arquivos, por exemplo, implementa um namespace.  O poema
> de Camões, armazenado no sistema de arquivos, é identificado pelo nome
> 
>   /poemas/cam.txt
> 
> O nome 
> 
>   /poemas
> 
> identifica a diretoria ``poemas'', que se localiza na diretoria raiz do
> sistema de arquivos.  
> 
> Quando você pede ao kernel pra aplicar um chroot a um determinado
> processo P numa determinada diretoria como
> 
>   /jaula
> 
> o kernel faz com que P passe a enxergar a diretoria raiz / como sendo a
> diretoria /jaula.  Isso efetivamente impede P de acessar qualquer
> elemento do sistema de arquivos que esteja fora de /jaula.  Por exemplo,
> P não consegue acessar /etc/passwd porque, para P, o arquivo /etc/passwd
> é na verdade /jaula/etc/passwd, uma vez que ``/'' é na verdade
> ``/jaula''.
> 
> (*) Uma árvore de processos UNIX implementa um namespace
> 
> Note que ``processo'' é distinto de ``programa''.  Um programa é uma
> sequência de instruções de máquina.  Um processo é uma instância desse
> programa em memória.  Um processo possui um PID.  Um programa não.
> 
> Cada processo tem um PID.  Logo, cada PID identifica um processo.  Um
> sistema sempre UNIX usa um processo de PID 1.  Só um processo pode ter o
> PID 1.  Se por ventura você desejar rodar dois processos com PID 1, você
> vai precisar de dois namespaces para processos.
> 
> No kernel Linux, só existe uma forma de criar processos: pedindo ao
> sistema para duplicar o processo em execução, o que é feito pela chamada
> do sistema de nome clone().  Ao invocar clone(), você tem a chance de
> pedir por várias coisas.  Por exemplo, você pode pedir por
> 
>   CLONE_NEWPID
> 
> e então um novo ``PID namespace'' é criado para o novo processo que
> clone produz.  (Se você não pede por CLONE_NEWPID, então o novo processo
> criado vive no mesmo PID namespace que seu processo pai --- o processo
> que invocou clone().)
> 
> Similar ao pedido CLONE_NEWPID, existe o pedido 
> 
>   CLONE_NEWNET,
> 
> o que lhe concede um novo namespace relativo à rede.  (Você poderia por
> exemplo construir uma tabela de roteamento diferente da usada em seu
> namespace original de rede.  Cabe notar que uma placa de rede, por
> exemplo, só pode pertencer a um namespace de cada vez.  Se você quer
> testar um programa de rede numa configuração de rede diferente da sua
> atual, você precisaria, por exemplo, de uma interface de rede virtual.)
> 
> Similar a esses, existe o pedido 
> 
>   CLONE_NEWNS,
> 
> que lhe dá um novo namespace para o sistema de arquivos, o que te
> permite por exemplo usar o nome /etc/passwd como o nome de um arquivo
> completamente diferente do seu original.  
> 
> As vantagens de CLONE_NEWNS você já conhece bem.  Você anda interessado
> em CLONE_NEWPID e CLONE_NEWNET.  A forma usuário-final típica de usar
> esses recursos é pilotando um software como Docker ou concorrentes.
> Tecnicamente, você pode escrever seu próprios programas e obter o mesmo
> efeito ``si hablas un poco del lenguaje C, el lenguaje UNIX''.
> 

Às vezes faz falta uma boa formalização de conceitos.
Bom post!

Cumps.

[toc] | [prev] | [next] | [standalone]

#2856

On 04/07/20 05:29, Paulo da Silva wrote:
               ^
Hei, tu dormes?

[toc] | [prev] | [next] | [standalone]

#2859

Às 09:02 de 04/07/20, Ninguém escreveu:
> On 04/07/20 05:29, Paulo da Silva wrote:
>               ^
> Hei, tu dormes?
Quando calha :-) Não tenho horários.

[toc] | [prev] | [next] | [standalone]

#2855

Boa! Gostei.
E obrigado pelas correções.

Mas quanto ao docker, então... não estou a ver grande vantagem.
Se consigo implementar tudo com systemd-nspawn (o docker usa-o) que 
vantagem traria o docker?

[toc] | [prev] | [next] | [standalone]

#2858

Ninguém <usenet@rasparta.org> writes:

[...]

> Mas quanto ao docker, então... não estou a ver grande vantagem.
> Se consigo implementar tudo com systemd-nspawn (o docker usa-o) que
> vantagem traria o docker?

O systemd-nspawn não cria um namespace de rede pra você.  Se você não
precisa de uma rede nova no seu laboratório, então você não precisa de
um novo namespace de rede e, assim, o systemd-nspawn parece suficiente.
Você não ficaria sem rede nesse laboratório; a rede do seu laboratório
seria a mesma rede do sistema anfitrião.

Note que nunca executei nem o systemd-nspawn nem o Docker.  Nem nunca li
os manuais de qualquer deles.  Não sei em detalhes o que cada um faz.  O
que sei sobre eles é o que posso afirmar sobre qualquer programa UNIX.

[toc] | [prev] | [next] | [standalone]

#2850

On 03/07/20 10:16, Patricia Ferreira wrote:
> O senhor é ousado também.:-D

É. Tenho aqui alguém que me está sempre a elogiar desse jeito:
Teimoso, abusado, inconveniente... :-D

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | pt.comp.so.linux

csiph-web