TUTORIAL: "bash: sysctl: comando não encontrado" como resolver

Ferox Graxaim · 20 de setembro

Boa tarde pessoal! Esses tempos eu estava tentando rodar DayZ no Debian, mas para o DayZ funcionar corretamente é necessário adicionar o seguinte comando no terminal:

sudo sysctl -w vm.max_map_count=1048576

Mas ocorreu comigo o erro de comando não encontrado.
Pesquisando em sites gringos, descobri que o problema é que o sistema não reconhece a pasta onde está o comando sysctl, que no caso é /sbin.

Para resolver o problema temporariamente, basta executar no terminal o seguinte comando:

export PATH=$PATH:/sbin

Para uma solução permanente, basta adicionar essa linha no final do seu arquivo $HOME/.profile ou $HOME/.bashrc, ou até mesmo com o programa "Aplicativos de Inicialização".

Espero que isso ajude vocês a resolverem este problema!

Marcos FRM · 21 de setembro

22 horas atrás, Ferox Graxaim disse:

Pesquisando em sites gringos, descobri que o problema é que o sistema não reconhece a pasta onde está o comando sysctl, que no caso é /sbin.

O openSUSE também faz isso. Ainda bem que essa bobagem foi extirpada do Fedora e RHEL há dezesseis anos: https://fedoraproject.org/wiki/Features/SbinSanity.

22 horas atrás, Ferox Graxaim disse:

Para resolver o problema temporariamente, basta executar no terminal o seguinte comando:

Você pode simplesmente chamar o comando usando o caminho absoluto: /sbin/sysctl … .

Contudo, tem um jeito melhor. Crie um arquivo /etc/sysctl.d/dayz-agora-vai.conf (o nome pode ser qualquer coisa, desde que termine com .conf) contendo:

vm.max_map_count = 1048576

Ao iniciar, será aplicado.

Ferox Graxaim · 21 de setembro

2 horas atrás, Marcos FRM disse:

Você pode simplesmente chamar o comando usando o caminho absoluto: /sbin/sysctl … .

Contudo, tem um jeito melhor. Crie um arquivo /etc/sysctl.d/dayz-agora-vai.conf (o nome pode ser qualquer coisa, desde que termine com .conf) contendo:

Isso não é necessário, só de executar o comando uma vez no terminal o DayZ já funciona pra sempre.

Marcos FRM · 21 de setembro

Não deveria, pois sysctl modifica /proc/sys durante a execução apenas[1]; ou seja, não é permanente. Depois de reiniciar ou desligar, voltará à configuração de antes do comando ser executado. O método que mencionei torna a modificação permanente, sem sudo, sem mexer no PATH; é o local mais ou menos "oficial" para esse tipo de ajuste[2].

[1] https://man7.org/linux/man-pages/man8/sysctl.8.html

[2] https://man7.org/linux/man-pages/man5/sysctl.d.5.html

arfneto · 22 de setembro

20 horas atrás, Marcos FRM disse:

O openSUSE também faz isso. Ainda bem que essa bobagem foi extirpada do Fedora e RHEL há dezesseis anos

É um jeito de ver as coisas. Mas pode não ser assim "bobagem".

Mas mesmo antes desses 16 anos a ideia disso era manter comandos potencialmente disruptivos fora do alcance de usuários comuns.

Muitos comandos em sbin tem alcance global e podem afetar a vida de TODOS usuários do sistema.

Convém lembrar que Unix --- ok, Linux, MacOS, Android --- é um sistema multi usuário.

Imagine um infeliz com acesso a essas coisas e um tutorial de sei lá o que e brincando com route e criando rotas a olho, ou um outro brincando de fdisk ou dd e zerando discos inteiros, montando partições sem sentido ou outras centenas de bobagens desse tipo...

Pode ser melhor criar links simbólicos para comandos de sbin cuidadosamente escolhidos e colocar em bin. Ou mesmo criar clones em bin sem acesso a funções perigosas.

Existe uma tendência hoje em dia de ver o computador como existindo só para o usuário que está ali em frente ao teclado, por exemplo perguntando ou respondendo num forum como esse. Mas nem sempre é assim. É como achar que a LAN existe apenas para acessar a internet. Ou que o cabo de rede é o cabo "de internet".

20 horas atrás, Marcos FRM disse:

O openSUSE também faz isso. Ainda bem que essa bobagem foi extirpada do Fedora e RHEL há dezesseis anos: https://fedoraproject.org/wiki/Features/SbinSanity.

direto desse link:

Historically, Fedora enforces the split between /bin and /sbin by leaving
 /sbin and /usr/sbin out of the PATH for normal users. However, binaries
 that are commonly used for information-gathering (ifconfig, route) by
 normal users should not be placed out of their reach. Things that are
 commonly run with sudo should also be in PATH

Algo assim em português

historicamente, Fedora reforça a divisão enre /bin e /sbin deixando
 /sbin e /usr/sbin fora do PATH para usuários normais. No entanto,
 programas que são normalmente usados para coleta de informações
 (ifconfig, route) por usuários normais não deveriam ser colocados
 fora do alcance desses usuários. Coisas que normalmente rodam
 via sudo deveria estar também no PATH (para usuários comuns).

Muitos diriam que isso é uma bobagem enorme. Além de ter erros.

Algo da realidade, para o Fedora e todos Unix:

route e ifconfig não são comandos para coleta de informações. Podem ser usados para tal, mas um route pode fixar uma rota para qualquer rede, ifconfig pode desabilitar uma placa de rede, e muitos dos comandos em /usr/sbin podem deixar a máquina inutilizável. E pode mesmo ser irreversível, como um dd if=/dev/null of=x onde x seja uma partição do sistema
não sei de onde vem /sbin que não é nada comum de existir
coisas que rodam via sudo deveriam permanecer FORA DO ALCANCE do usuário comum
isso leva a uma situação impossível de administrar. Nem dá pra imaginar o que um usuário pode fazer com acesso a /usr/sbin. E assim pode nem dar pra corrigir um problema causado por um usuário desses.

Na wiki do Fedora alguém pode achar Sanity permitir isso. Aqui no forum também.

Mas é insanidade administrar uma máquina em que todos usuários estejam no grupo 0 por exemplo, todos com acesso a tudo. Mesmo que seja um usuário apenas, sudo é um seguro contra momentos de insanidade também desse único usuário com preguiça de usar su ou sudo. Basta fazer ssh para uma máquina e achar que está usando outra, por 30s. É a lei. Lei de Murphy.

Marcos FRM · 22 de setembro

O pessoal do Fedora felizmente irá além na futura versão 42, acabando de vez com sbin:

https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

Palmas para eles por modernizarem a distribuição. Não são pioneiros nisso, contudo. O Arch Linux fez essa modificação há mais de dez anos.

arfneto · 23 de setembro

10 horas atrás, Marcos FRM disse:

Palmas para eles por modernizarem a distribuição. Não são pioneiros nisso, contudo. O Arch Linux fez essa modificação há mais de dez anos.

Considere o que eu expliquei. Dei exemplos concretos. O novo artigo que citou parece ter sido escrito pelo mesmo sujeito com o mesmo discurso. seria você mesmo, @Marcos FRM?

Acha mesmo esperto deixe qualquer usuário rodar route, dd, ifconfig, fdisk e tudo que tem em sbin? ok então.

10 horas atrás, Marcos FRM disse:

Palmas para eles por modernizarem a distribuição. Não são pioneiros nisso, contudo. O Arch Linux fez essa modificação há mais de dez anos.

Bem moderno mesmo. Pouco esperto no entanto. Exceto para aqueles usuários que sabem muito, e outros que acham que sabem muito, e ouros que acham que níveis de usuário são um porre e uma restrição à liberdade das pessoas.

Imagino que estejam esperando também a promoção --- "modernização"--- das contas de usuário no Windows também, para todo mundo poder instalar programas e reconfigurar suas máquinas.

Imagino que não pague alguém para administrar 40 máquinas dessas com 30 usuários cada...

Esse tipo de afirmação do link "commonly used for information-gathering (ifconfig, route) by normal users" é um erro conceitual, para não usar uma palavra menos elogiosa. Esses não são comandos para coleta de dados, não são usados frequentemente por usuários comuns, e são conhecidos geradores de problemas para o sistema como um todo.

Não há razão para normal users usarem route ou ifconfig nem mesmo para coletar informações a respeito de rotas ou rede. Se isso é importante em um sistema alguém escreva um programa de poucas linhas que dá essa informação e não mais que isso. Um script ou um simples programa em C. E instala em bin para que todo usuário possa rodar.

Linux é um sistema multi-usuário. Desde sempre. Mesmo que rode em máquinas de um único usuário de "grande" conhecimento, moderno e que aprecia conceitos de liberdade de acesso.

De todo modo é só uma opinião.

Ferox Graxaim · 27 de setembro

Em 21/09/2024 às 18:45, Marcos FRM disse:

Não deveria, pois sysctl modifica /proc/sys durante a execução apenas[1]; ou seja, não é permanente. Depois de reiniciar ou desligar, voltará à configuração de antes do comando ser executado. O método que mencionei torna a modificação permanente, sem sudo, sem mexer no PATH; é o local mais ou menos "oficial" para esse tipo de ajuste[2].

[1] https://man7.org/linux/man-pages/man8/sysctl.8.html

[2] https://man7.org/linux/man-pages/man5/sysctl.d.5.html

Me confundi, achei que fosse solução definitiva, mas aí fui jogar o DayZ após reiniciar e lembrei que eu colocava o comando no "Aplicativos de Inicialização".