"Route not found" no Debian

Você está usando o Debian e quer ver quais as rotas configuradas no seu sistema. Um comando útil para isto é route. Porém quando vocë dá o comando:

$ route
bash: route: command not found

Existem normalmente dois motivos para que isto aconteça. O primeiro motivo é que o caminho para route não está configurado para seu usuário, pois ele fica em /sbin. Quando você procura usando whereis, o sistema não retorna. Note no segundo comando abaixo que /sbin não está no path.

$ whereis route:
route:
$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/snap/bin

Assim você pode simplesmente chamá-lo usando o caminho completo /sbin/route.

Contudo, pode ser que mesmo assim você não ache o comando. 




$ /sbin/route
bash: /sbin/route: No such file or directory

Isto ocorre porque o pacote net-tools não está instalado. Para instalar basta:

$ sudo apt install net-tools

Agora finalmente o comando deve funcionar. Note que ainda assim o caminho não está no PATH, portanto você precisa colocar o caminho completo.

$ route -n
bash: route: command not found

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.2.2        0.0.0.0         UG    100    0        0 enp0s3
10.0.2.0        0.0.0.0         255.255.255.0   U     100    0        0 enp0s3
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp0s3

Parametros do BIND para fazer uma migração de IP em seu domínio

Existem duas configurações diferentes para o TTL padrão nos arquivos do  DNS (BIND) que você precisa alternar quando for alterar o endereço IP de um ou mais servidores para um endereço IP diferente.
Neste post estamos considerando a versão 9 do BIND, mas o conceito deve funcionar para a maioria dos DNS. Podendo, contudo, alterar com cada parâmetro é configurado.


As configurações que você terá que fazer são:

1. configuração de armazenamento em cache negativo no registro SOA. Este parâmetro é última entrada do registro SOA. Normalmente, o TTL padrão é definido como um dia, que é 86400 segundos. Para obter mais informações sobre cache negativo, consulte rfc2308.
2. TTL padrão na parte superior do arquivo (é uma linha começada com $ttl). O valor padrão para este campo é definido como 86400.
3. Pode ser que existam ainda casos pontuais nas linhas de configuração do seu arquivo, pois o BIND permite que você tenha configurações TTL diferentes para cada registro individual. Neste caso você terá mais trabalho pois será necessário defini-las também. 

Se os valores do cache negativo no registro SOA e do TTL padrão estiverem nos valores default, isso significa que respostas negativas e consultas positivas serão armazenadas em cache por um dia.


No exemplo a seguir, mudamos os TTLs para 14400 que corresponde a 4 horas:

$ORIGIN meudominio.com.br.
$TTL    14400          ; 4H (ttl)
@       IN  SOA ns.meudominio.com.br.   admin.meudominio.com.br. (
            2020012101 ; serial
            1H         ; refresh
            7200       ; retry = 7200 min
            14D        ; expiration time
            4H         ; ttl
            )

Note que em algumas linhas existem comentários, que começam com ponto e vírgula.

Colocar Ubuntu rodando somente texto

Em sistemas mais antigos bastava a gente acertar o runlevel para o nível 2.
O Ubuntu 18.04 usa systemd em vez de init (no 16.04 também já é assim),
O conceito de runlevels é substituído por "target", que é o modo de operação do linux.
Portanto, existe realmente um mapeamento entre os níveis de execução (runlevel) baseados em init e os destinos baseados em systemd como mostrado na tabela abaixo:

Assim para trocar para o runlevel 2, utilizamos os comando abaixo:

$ sudo systemctl isolate multi-user.target
$ sudo systemctl enable multi-user.target
$ sudo systemctl set-default multi-user.target

Tento executado estes comando, basta dar um reboot para que o sistema entre no runlevel 2. 


Observação: 
Para testar somente o runlevel, você pode dar

$ sudo init 2

Instalar o skype no Ubuntu pela linha de comando

A instalação na linha de comando no Ubuntu não deu muito problema no meu caso.
Basicamente basta entrar com a sequência de comandos abaixo no terminal (digite CTRL+ALT+T para abri-lo na interface gráfica).
Pode ser que no seu caso apt-transport-https já esteja instalado (no meu estava), contudo não tem problema dar o comando, pois a única coisa que irá acontecer é que vai demorar alguns segundos a mais e o Ubuntu dar um aviso que já está instalado.

$ echo "deb [arch=amd64] https://repo.skype.com/deb stable main" | sudo tee /etc/apt/sources.list.d/skype-stable.list
$ wget https://repo.skype.com/data/SKYPE-GPG-KEY
$ sudo apt-key add SKYPE-GPG-KEY
$ sudo apt install apt-transport-https
$ sudo apt update
$ sudo apt install skypeforlinux

Tento finalizado com sucesso a instalação. Você dever digitar o comando abaixo no terminal para abrir a interface gráfica do Skype.

$ skypeforlinux

Basta fazer o login, permitir acesso ao microfone, câmera, etc. e pronto.

Como forçar o APT a usar IPv4

Para forçar o APT a usar IPv4 no Ubuntu e similares, abra o terminal (o atalho é Ctrl + Alt + T).
Os comandos serão dados como root, isto é, você tem que logar como root ou usar sudo.

Assim podemos forçar o APT a usar IPv4:

1- Para atualizar a lista de repositórios:

$ sudo apt-get -o Acquire::ForceIPv4=true update

2- Para atualizar o sistema:

$ sudo apt-get -o Acquire::ForceIPv4=true upgrade

3- instalar algum pacote:

$ sudo apt-get -o Acquire::ForceIPv4=true install nome-do-pacote

Note que você sempre terá que colocar a opção nos comandos acima.
Contudo se você quiser fazer com que essas mesmas instruções sejam executadas sempre que o sistema for iniciado, precisamos adicionar uma linha em  /etc/apt/apt.conf.d/99force-ipv4, utilizando a linha de comando abaixo:

$ echo 'Acquire::ForceIPv4 "true";' | sudo tee /etc/apt/apt.conf.d/99force-ipv4

Forçar o cliente SSH a usar autenticação por senha em vez de chave pública

Eu estava precisando conectar em um computador via SSH, contudo meu cliente só tentava fazer a conexão utilizando as chaves de criptografia, contudo eu não tinha a chave do servidor, somente usuário e senha.
Assim eu precisava forçar o cliente SSH a conectar usando autenticação de senha e negar explicitamente a autenticação de chave pública.
Isto pode ser feito acrescentando alguns parâmetros à chamada SSH mostrados abaixo.
Note que no meu caso eu precisava informar a porta de conexão usando -p 22222. Se seu servidor usa a porta padrão (22) pode omitir esta parte.

ssh -p 22222 -o PreferredAuthentications=password -o PubkeyAuthentication=no usuario@servidor

Os mesmos parâmetros são validos em uma chamada para copiar arquivos usando scp (secure copy):

scp -p 22222 -o PreferredAuthentications=password -o PubkeyAuthentication=no nome_do_arquivo usuario@servidor:destino/nome_do_arquivo

userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]

Se você acabou de atualizar o Ubuntu para as versões 16 ou 18, pode ser que você obtenha um erro de conexão em função da nova forma de operação do OpenSSH.
O OpenSSH quando mudou da versão v6.9 para a v7.0 recusa conexões de ssh devido a alterações no formato do arquivo de configuração.

No meu caso o seguinte erro aparecia no arquivo /var/log/auth.log do computador que eu queria conectar

sshd[6850]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
sshd[6850]: error: maximum authentication attempts exceeded for root from x.x.x.x port 51702 ssh2 [preauth]
sshd[6850]: Disconnecting authenticating user root x.x.x.x port 51702: Too many authentication failures [preauth]

Para resolver este erro foi preciso editar o arquivo /etc/sshd_config e acrescentar a seguinte linha no final do arquivo de configuração:

PubkeyAcceptedKeyTypes=+ssh-dss

Agora foi só reiniciar o ssh usando service ssh restart, e a conexão passou a ser reconhecida.
Esta configuração vale para todos os usuários.
Você pode acrescentar esta linha em  ~/.ssh/config para o usuário local.