Slackware Linux
Boas novas!
O Slackware já está a usar o kernel 5.4.1 na versão current. Mas talvez ainda seja boa ideia esperar uns dias, até que os pacotes mais importantes sejam atualizados para tirar partido desta nova versão do kernel.
Daqui a uns dias, testo este novo kernel e do feedback por aqui.
Última Hora
Acabou de sair o Kernel 5.4.0
O Slackware current já contém, na diretoria testing, o kernel 5.4.0_rc8.
É muito provável que o Patrick se esteja a preparar para lançar o Slackware 15 com a primeira versão estável deste novo kernel.
Aguardemos.
Desde que o Slackware começou a usar o Postfix e o Dovecot como servidores de email e imap, que tem sido uma dor de cabeça tentar configurá-los.
Ontem voltei a tentar e já tenho um servidor a funcionar minimamente.
Os sites que usei para ver como configurar o Postfix foram [1], [2] e [3].
Para o Dovecot usei o site [1]. Estou a ler também [2] para tentar configurar o IMAPS.
Para o Postfix, editei o ficheiro /etc/postfix/main.cf e adicionei as linhas seguintes:
mydomain = myserver.pt
myorigin = $mydomain
inet_interfaces = all
mydestination = localhost.$mydomain, localhost, $mydomain
mynetworks = 192.168.0.0/16, 127.0.0.0/8
relay_domains = $mydestination
relayhost = [my-relay-server.pt]
smtpd_recipient_restrictions =
reject_unauth_destination
reject_rbl_client zen.spamhaus.org=127.0.0.[2..11]
reject_rbl_client b.barracudacentral.org=127.0.0.2
Para o Dovecot, editei o ficheiro /etc/dovecot/dovecot.conf e adicionei as linhas seguintes:
protocols = imap listen = *, :: login_trusted_networks = 192.168.0.0/16
Depois, na diretoria /etc/dovecot/conf.d:
Editei o ficheiro 10-logging.conf e adicionei as linhas seguintes:
log_path = /var/log/dovecot/dovecot.log
Editei o ficheiro 10-mail.conf e adicionei as linhas seguintes:
mail_location = mbox:~/mail:INBOX=/var/spool/mail/%u mail_access_groups = mail
A configuração anterior mail_access_groups = mail é perigosa, pois permite que utilizadores com shell no login, tenham acesso às caixas de correio dos outros. Havia uma outra alternativa para resolver um erro que o Dovecot dava, mas não a compreendi.
Sem esta configuração, o erro que surgia no ficheiro de log era:
Error: fchown(/home/user/mail/.imap/INBOX, group=12(mail)) failed: Operation not permitted (egid=1000(user), group based on /var/spool/mail/user - see http://wiki2.dovecot.org/Errors/ChgrpNoPerm)
Editei o ficheiro 10-ssl.conf e adicionei as linhas seguintes:
ssl = no
E comentei também as linhas seguintes, enquanto não configuro o IMAPS.
#ssl_cert = </etc/ssl/certs/dovecot.pem #ssl_key = </etc/ssl/private/dovecot.pem
Para testar se o dovecot está a funcionar bem, executei o comando seguinte:
mutt -f imap://user@myserver.pt
Vou começar por configurar as máquinas mais simples, e mudá-las do sendmail/imapd para o postfix/dovecot. Quando estiver tudo a funcionar, vou tentar configurar também a máquina mais complexa, que serve de relay às outras.
O PHP 7.2 deixou de ter suporte para as funções do módulo MCrypt.
Durante algum tempo tive uma máquina virtual com uma versão antiga do PHP, para poder receber dados cifrados por uma aplicação Android que desenvolvi. Hoje decidi resolver o problema e descobri que a solução era muito mais fácil do que pensava ser.
Para ter acesso às funções do módulo MCrypt, bastou instalar o módulo MCrypt do PECL, com o seguinte comando:
pecl install mcrypt
Antes disso, tive que atualizar o PHP da versão antiga para a versão atual 7.3.11. E depois, tive que incluir a seguinte linha no ficheiro php.ini:
extension=mcrypt
Reiniciei o Apache, e as funções mcrypt já estão disponíveis.
Para fazer grep, numa diretoria, em ficheiros com uma determinada extensão, usa-se o comando seguinte:
grep -r --include \*.php --include \*.html jquery *
O comando anterior pesquisa numa árvore de diretorias, a partir da diretoria atual, todos os ficheiros *.php e *.html, à procura da string jquery.
Já há algum tempo que queria começar a usar o Unicode em consola no Slackware.
Há uns meses atrás, tentei, mas a informação disponível dizia que era difícil, que havia dificuldade com línguas diferentes do inglês/americano.
Afinal, e segundo um documento recente que encontrei aqui é relativamente fácil.
Basicamente, é apenas necessário editar os ficheiros /etc/profile.d/lang.sh e /etc/profile.d/lang.csh e atualizar a linha seguinte:
export LANG=pt_PT.UTF-8
Depois, editar o ficheiro /etc/lilo.conf e adicionar/modificar a linha seguinte:
append="vt.default_utf8=1"
No fim, correr o comando lilo e reiniciar a máquina.
Eis os comandos necessários para compilar o VirtualBox:
cd /root bat/vboxes stop cd /usr/local/ VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack" reboot exit cd /usr/local/ chmod +x ./VirtualBox-X.X.XX-XXXXX-Linux_amd64.run ./VirtualBox-X.X.XX-XXXXX-Linux_amd64.run VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-X.X.XX-XXXXX.vbox-extpack cd - bat/vboxes start
Nota : o ficheiro bat/vboxes é um ficheiro de comandos que criei para gerir as máquinas virtuais do VirtualBox. Já agora, este script serve para lançar as máquinas virtuais em modo headless e tem o conteúdo seguinte:
#!/bin/sh
# PATH should only include /usr/* if it runs after the mountnfs.sh script
PATH=/usr/sbin:/usr/bin:/sbin:/bin
SCRIPTNAME=/root/bat/vboxes
MANAGE_CMD=/root/bat/vboxcase "$1" in
start|stop|shutdown|restart|force-reload)
echo "-- $1 virtual boxes --"
;;
*)
echo "Usage: $SCRIPTNAME {start|stop|shutdown|restart|force-reload}" >&2
exit 3
;;
esac
for i in `VBoxManage list vms | grep "^\"" | sed -e "s/{.*}//g" | sed -e "s/\"//g"`;
do
echo "$MANAGE_CMD $i $1"
$MANAGE_CMD $i $1
done
No script anterior faço referência a um outro script bat/vbox cujo conteúdo se segue e serve para gerir uma máquina virtual de cada vez (ver código original aqui)):
#!/bin/sh
### BEGIN INIT INFO
# Provides: vbox
# Required-Start:$local_fs $remote_fs vboxdrv vboxnet
# Required-Stop: $local_fs $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: MAQUINA virtual machine
# Description: MAQUINA virtual machine hosted by VirtualBox
### END INIT INFO# Author: Brendan Kidwell <brendan@glump.net>#
# Based on /etc/init.d/skeleton from Ubuntu 8.04. Updated for Ubuntu 9.10.
# If you are using Ubuntu <9.10, you might need to change "Default-Stop" # above to "S 0 1 6". # Do NOT "set -e" # O nome da máquina tem que vir como 1º parâmetro # O nome do comando tem que vir como 2º parâmetro MAQUINA="$1" COMANDO="$2" # PATH should only include /usr/* if it runs after the mountnfs.sh script PATH=/usr/sbin:/usr/bin:/sbin:/bin DESC="$MAQUINA virtual machine" NAME=vbox SCRIPTNAME=/root/bat/$NAME MANAGE_CMD=VBoxManage VM_OWNER=root VM_NAME="$MAQUINA" #This has to be the name exactly as it appears in your VirtualBox GUI control panel. # Read configuration variable file if it is present [ -r /etc/default/$NAME ] && . /etc/default/$NAME # Load the VERBOSE setting and other rcS variables [ -f /etc/default/rcS ] && . /etc/default/rcS # Define LSB log_* functions. # Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
#. /lib/lsb/init-functions
#
# Function that starts the daemon/service
#
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo "$VM_NAME"|grep "^State:\s*running" >/dev/null && {
echo "$VM_NAME" is already running.
return 1
}
sudo -H -u $VM_OWNER $MANAGE_CMD startvm "$VM_NAME" -type headless >/dev/null || {
echo Failed to start "$VM_NAME".
return 2
}
echo "$VM_NAME" started or resumed.
return 0
}
#
# Function that stops the daemon/service
#
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo "$VM_NAME"|grep "^State:\s*running" >/dev/null || {
echo "$VM_NAME" is already stopped.
return 1
}
sudo -H -u $VM_OWNER $MANAGE_CMD controlvm "$VM_NAME" savestate || {
echo Failed to stop "$VM_NAME".
return 2
}
echo "$VM_NAME" suspended.
return 0
}
#
#
# Function that powers off the daemon/service
#
do_shutdown()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo "$VM_NAME"|grep "^State:\s*running" >/dev/null || {
echo "$VM_NAME" is already stopped.
return 1
}
sudo -H -u $VM_OWNER $MANAGE_CMD controlvm "$VM_NAME" acpipowerbutton || {
echo Failed to stop "$VM_NAME".
return 2
}
echo "$VM_NAME" powered off.
return 0
}
#
# Display "State" field from showinfo action
#
do_status()
{
sudo -H -u $VM_OWNER $MANAGE_CMD showvminfo "$VM_NAME"|grep "^State:\s*.*$"
}
case "$COMANDO" in
start)
[ "$VERBOSE" != no ] && logger "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && logger 0 ;;
2) [ "$VERBOSE" != no ] && logger 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && logger "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && logger 0 ;;
2) [ "$VERBOSE" != no ] && logger 1 ;;
esac
;;
shutdown)
[ "$VERBOSE" != no ] && logger "Powering off $DESC" "$NAME"
do_shutdown
case "$?" in
0|1) [ "$VERBOSE" != no ] && logger 0 ;;
2) [ "$VERBOSE" != no ] && logger 1 ;;
esac
;;
restart|force-reload)
#
# If the "reload" option is implemented then remove the
# 'force-reload' alias
#
logger "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
do_start
case "$?" in
0) logger 0 ;;
1) logger 1 ;; # Old process is still running
*) logger 1 ;; # Failed to start
esac
;;
*)
# Failed to stop
logger 1
;;
esac
;;
status)
do_status
;;
*)
#echo "Usage: $SCRIPTNAME nome-maquina {start|stop|shutdown|restart|reload|force-reload}" >&2
echo "Usage: $SCRIPTNAME nome-maquina {start|stop|shutdown|restart|force-reload|status}" >&2
exit 3
;;
esac
Usei outro script logo no arranque da máquina (host) para criar placas de rede virtuais para serem usadas pelas máquinas virtuais. São criadas como uma ponte (bridge) para uma placa física no host que só serve para rencaminhar o tráfego das máquinas virtuais para a rede e vice-versa. O seu conteúdo é o seguinte:
#!/bin/sh # set PATH for the case we are called via sudo or su root # PATH=/sbin:/usr/bin:/bin:/usr/binUSER=root NUMBER_OF_VM=9 # create the bridge brctl addbr br0 # create the taps and insert them into the bridge NB=1 while [ $NB -le $NUMBER_OF_VM ] do tunctl -t tap$NB -u $USER ip link set up dev tap$NB brctl addif br0 tap$NB let NB=$NB+1 done ip route add 192.168.40.0/24 dev eth1 # set the IP address and routing ip link set up dev br0 ip addr add 192.168.40.1/24 dev br0 ##ip route add 192.168.40.0/24 dev br0 brctl addif br0 eth1
Já há uns anos que uso a versão current do Slackware. Com alguma frequência, atualizo as minhas máquinas todas para a última versão dos vários pacotes. Algumas são máquinas virtuais, outras são máquinas físicas, duas delas têm o VirtualBox.
Durante as atualizações, têm surgido vários problemas, e tenho escrito artigos soltos sobre as soluções encontradas para os resolver. Vou tentar copiar para esta crónica, toda a lista de problemas e soluções que estão espalhadas por este blog.
Eis a lista de comandos que utilizo no Slackware para fazer update das minhas máquinas, a partir de um mirror que tenho e que é atualizado diariamente.
slackpkg update slackpkg update gpg slackpkg install-new slackpkg upgrade-all slackpkg clean-system
De vez em quando, e ainda não percebi porquê, o slackpkg pendura. A máquina que estava a ser atualizada deixa de responder. Não sei se é por fazer muitas atualizações em simultâneo, todas a ler no mesmo mirror, se é demasiado peso na rede a carregar os pacotes para as atualizações… Duvido que a causa seja uma destas, mas ainda não consegui descobrir a origem dos problemas.
Algumas vezes tenho que mandar a máquina abaixo, embora nem sempre. Mas uma consequência chata destes penduranços é que os pacotes que estavam a ser atualizados são considerados instalados, apesar de não estarem. Ainda demorei algum tempo a encontrar solução para este problema, por isso fica aqui para consulta futura.
cd /var/lib/slackpkg/ rm ChangeLog.txt
E depois já posso recomeçar os updates.
Há cerca de um ano (em 2018), o Slackware passou a avisar que instalou um novo kernel, mas já não corre o lilo; pede antes que sejamos nós a fazê-lo.
Se me esquecer de correr o lilo numa máquina virtual, a solução para voltar a arrancar com ela é a seguinte:
Nos settings da máquina, no VirtualBox, pedir para arrancar com o ISO da versão mais recente do Slackware. Depois de entrar, correr os seguintes comandos:
mount /dev/sda2 /mnt chroot /mnt lilo reboot
Se me esquecer de correr o lilo num host das máquinas virtuais (que têm o disco de boot em RAID 1), a solução é arrancar de DVD e correr os seguintes comandos:
mdadm --assemble --run /dev/md0 /dev/sda2 /dev/sdb2 mount /dev/md0 /mnt chroot /mnt lilo exit reboot
Depois de recuperar a máquina que pendurou nas atualizações, retomei o processo de atualização e recebi uma mensagem à qual nunca soube responder:
Checking local integrity... DONE You have a broken /var/log/packages - with two versions of the same package. The list of packages duplicated in your machine are shown below, but don't worry about this list - when you select your action, slackpkg will show a better list: llvm-3.8.0-x86_64-1 llvm-3.8.0-x86_64-2 You can (B)lacklist, (R)emove, or (I)gnore these packages. Select your action (B/R/I):
Premi ENTER, sem escolher opção nenhuma e fui à net@ ver o que deveria fazer. Descobri que devia remover o pacote llvm-3.8.0-x86_64-1 que não tinha sido removido na instalação anterior, que pendurou. Removi-o com o comando:
removepkg llvm-3.8.0-x86_64-1
e depois continuei a atualização com:
slackpkg upgrade-all
Para atualizar a versão do VirtualBox nos hosts das máquinas virtuais, uso os comandos seguintes:
cd /root bat/vboxes stop cd /usr/local/ VBoxManage extpack uninstall "Oracle VM VirtualBox Extension Pack" reboot exit cd /usr/local/ chmod +x ./VirtualBox-X.X.X-XXXXXX-Linux_amd64.run ./VirtualBox-X.X.X-XXXXXX-Linux_amd64.run VBoxManage extpack install Oracle_VM_VirtualBox_Extension_Pack-X.X.X-XXXXXX.vbox-extpack cd /root bat/vboxes start
O ficheiro bat/vboxes é um ficheiro de comandos que criei para gerir as máquinas virtuais do VirtualBox. [ver aqui]
Entretanto, se alguma das máquinas falhar, posso recuperá-la da forma seguinte (para casos em que há problemas com o kernel):
Reiniciar a máquina virtual, ligando ao leitor de CD um ISO com a última versão do sistema operativo. Depois de arrancar e escolher o layout do teclado, executar os comandos seguintes.
mount /dev/sda2 /mnt mount -t proc proc /mnt/proc (this was the magic step) chroot /mnt cd /boot mkinitrd -c -k 4.14.2 -m ext3 # No ficheiro /etc/lilo.conf colocar a linha initrd = /boot/initrd.gz # no fim do ficheiro, logo após a linha root = /dev/sda2 # depois, executar os comandos: lilo reboot
A nova configuração do SSHD, no Slackware, não permite o acesso de clientes à conta “root”. Para permitir, é necessário, antes do último reboot, colocar a linha seguinte no ficheiro /etc/ssh/sshd_config: PermitRootLogin yes
Ou então apagar o ficheiro /etc/ssh/sshd_config.new antes de fazer o upgrade.
Ou, sempre que o SSHD é atualizado, não fazer o overwrite desse ficheiro.
Durante a atualização das máquinas, uma das máquinas virtuais deu um erro de input/output, enquanto estava a remover um pacote. E a atualização ficou por ali.
Tive que reiniciar a máquina, mas só o consegui fazer dentro do VirtualBox, e não em modo headless através de um ficheiro batch que uso para lançar as máquinas. Qualquer acesso ao sistema de ficheiros dava um erro de input/output (o df, o mount). Tentei retomar a atualização, mas a diretoria remota – onde estão os pacotes do Slackware – não estava montada. Descobri, então, que não tinha rede e o sistema não permitia fazer o modprobe da placa de rede: dizia que o dispositivo não existia na diretoria /lib/modules/4.4.13.
Fui à pasta /lib/modules/4.4.13 ver que dispositivos de rede estavam disponíveis, mas a pasta /lib/modules/4.4.13 não existia. No entanto, havia uma mais recente: /lib/modules/4.4.14.
Ah! Durante a atualização, o kernel 4.4.14 já tinha sido instalado, mas como não cheguei a correr o lilo, devido à interrupção da instalação, o sistema ainda estava a arrancar com o 4.4.13. Contudo, as bibliotecas do 4.4.13 já tinham sido removidas. Corri o lilo e reiniciei a máquina. Depois já pude mandar verificar o sistema de ficheiros, com um comando que desliga a máquina e força a verificação no próximo arranque:
shutdown -rF now
Tenho tido problemas com o BIND. Penso que é um problema de erros na cache, ou algo parecido. Quando tento aceder a um sítio a partir do nome, na rede interna, o browser diz que não consegue aceder ao sítio. Mas se eu aceder a partir das máquinas periféricas – os gateways – acedo sem problemas.
Independentemente do problema, aqui fica uma solução para limpar a cache do BIND.
Para fazer dump da cache:
rndc dumpdb -cache
Para ver o conteúdo do dump:
vi /var/named/named_dump.db
Para apagar a cache:
rndc flush
Depois é necessário recarregar o BIND:
rndc reload
Ver mais em: How to view and clear Bind DNS server’s cache on Linux