Estou usando um roteador Arch Linux para conectar-me à VPN do ISP e, por algum motivo, a autenticação CHAP foi rejeitada:

rcvd [LCP ConfReq id=0x1 <auth chap MD5> <mru 1436> <magic 0x5e9f9414>]
No auth is possible
sent [LCP ConfRej id=0x1 <auth chap MD5>]

Como isso pode ser consertado?

Informações completas

Histórico

root@Chiruno:~# pon wan debug dump logfd 2 nodetach
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
logfd 2         # (from command line)
ifname wan              # (from /etc/ppp/peers/wan)
dump            # (from command line)
noauth          # (from /etc/ppp/options.pptp)
refuse-pap              # (from /etc/ppp/options.pptp)
                # (from /etc/ppp/options)
                # (from /etc/ppp/options.pptp)
refuse-mschap-v2                # (from /etc/ppp/options.pptp)
refuse-eap              # (from /etc/ppp/options.pptp)
name username           # (from /etc/ppp/peers/wan)
remotename PPTP         # (from /etc/ppp/options.pptp)
                # (from /etc/ppp/options.pptp)
pty /usr/sbin/pptp pptp.isp --nolaunchpppd          # (from /etc/ppp/peers/wan)
ipparam $TUNNEL         # (from /etc/ppp/peers/wan)
defaultroute            # (from /etc/ppp/peers/wan)
replacedefaultroute             # (from /etc/ppp/peers/wan)
nobsdcomp               # (from /etc/ppp/options)
nodeflate               # (from /etc/ppp/options)
using channel 672
Using interface wan
Connect: wan <--> /dev/pts/6
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x6fec8267> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <auth chap MD5> <mru 1436> <magic 0x5e9f9414>]
No auth is possible
sent [LCP ConfRej id=0x1 <auth chap MD5>]
rcvd [LCP ConfRej id=0x1 <asyncmap 0x0> <pcomp> <accomp>]
sent [LCP ConfReq id=0x2 <magic 0x6fec8267>]
rcvd [LCP ConfReq id=0x2 <auth chap MD5> <mru 1436> <magic 0x5e9f9414>]
No auth is possible
sent [LCP ConfRej id=0x2 <auth chap MD5>]
Modem hangup
Connection terminated.
Script /usr/sbin/pptp pptp.isp --nolaunchpppd finished (pid 40392), status = 0x0

Configuração

/etc/ppp/options.pptp

###############################################################################
# $Id: options.pptp,v 1.4 2012/08/30 21:34:13 quozl Exp $
#
# Sample PPTP PPP options file /etc/ppp/options.pptp
# Options used by PPP when a connection is made by a PPTP client.
# This file can be referred to by an /etc/ppp/peers file for the tunnel.
# Changes are effective on the next connection.  See "man pppd".
#
# You are expected to change this file to suit your system.  As
# packaged, it requires PPP 2.4.2 or later from http://ppp.samba.org/
# and the kernel MPPE module available from the CVS repository also on
# http://ppp.samba.org/, which is packaged for DKMS as kernel_ppp_mppe.
###############################################################################

# Lock the port
lock

# Authentication
# We don't need the tunnel server to authenticate itself
noauth

# We won't do PAP, EAP, MSCHAP or MSCHAP-V2 but we will accept CHAP
# (you may need to remove these refusals if the server is not using MPPE)
refuse-pap
refuse-eap
refuse-mschap
refuse-mschap-v2

remotename PPTP

# Compression
# Turn off compression protocols we know won't be used
#nobsdcomp
#nodeflate

# Encryption
# (There have been multiple versions of PPP with encryption support,
# choose which of the following sections you will use.  Note that MPPE
# requires the use of MSCHAP-V2 during authentication)
#
# Note that using PPTP with MPPE and MSCHAP-V2 should be considered
# insecure:
# http://marc.info/?l=pptpclient-devel&m=134372640219039&w=2
# https://github.com/moxie0/chapcrack/blob/master/README.md
# http://technet.microsoft.com/en-us/security/advisory/2743314

# http://ppp.samba.org/ the PPP project version of PPP by Paul Mackarras
# ppp-2.4.2 or later with MPPE only, kernel module ppp_mppe.o
# If the kernel is booted in FIPS mode (fips=1), the ppp_mppe.ko module
# is not allowed and PPTP-MPPE is not available.
# {{{
# Require MPPE 128-bit encryption
#require-mppe-128
# }}}

# http://mppe-mppc.alphacron.de/ fork from PPP project by Jan Dubiec
# ppp-2.4.2 or later with MPPE and MPPC, kernel module ppp_mppe_mppc.o
# {{{
# Require MPPE 128-bit encryption
#mppe required,stateless
# }}}

/etc/ppp/peers/wan

pty "/usr/sbin/pptp pptp.isp --nolaunchpppd"
name username
remotename PPTP
require-chap
file /etc/ppp/options.pptp
ifname wan
ipparam $TUNNEL
defaultroute
replacedefaultroute

/etc/ppp/chap-secrets

# user          remote  secret          IP addresses
"username"      PPTP    "P4ssw0rd!1!"   *

Preciso poder alterar os idiomas enquanto estou trabalhando, então sempre que faço login, uso este comando:

setxkbmap -layout us,ua -option grp:toggle

Existe alguma maneira de executar esse comando toda vez que inicializo?

(setxkbmap -layout us,ua -option grp:toggle) & $(setxkbmap -layout us,ua -option grp:toggle)

não funcionou para mim, mas só tentei após a execução do meu gerenciador de janelas.

Atualmente, meu arquivo .xinitrc está assim:

/usr/bin/pipewire &
/use/bin/pipewire-pulse &


picom &
~/.fehbg

while true
do
    xsetroot -name "$(cat /sys/class/power_supply/BAT1/capacity)% | $(cat ~xenovar/mission.txt) | $(date +"%H:%M")"
    sleep 1m
done &
    
#exec startplasma-x11
exec dwm
$(setxkbmap -layout us,ua -option grp:toggle)

Estou ciente de que o Arch Linux não é suportado pelo chef.io, mas existe alguma maneira de inicializar os nós do Arch Linux usando o Knife Bootstrap?

Tentei o mesmo comando que uso em máquinas Debian, mas recebo um erro:

knife bootstrap 10.2.128.80 --ssh-identity-file ~/.ssh/id_rsa --connection-user myUser -N webserver --environment staging --bootstrap-version 18 -y --sudo

Connecting to 10.2.128.80 using ssh
Connecting to 10.2.128.80 using ssh

DEBUG: [SSH] [email protected] cmd = cmd.exe /c ver
DEBUG: [SSH] [email protected] cmd = Get-WmiObject Win32_OperatingSystem | Select Caption,Version | ConvertTo-Json
DEBUG: [SSH] [email protected] cmd = uname -s
DEBUG: [SSH] [email protected] cmd = uname -m
DEBUG: [SSH] [email protected] cmd = test -f /etc/debian_version
DEBUG: [SSH] [email protected] cmd = test -f /etc/os-release && cat /etc/os-release
DEBUG: [SSH] [email protected] cmd = show version
DEBUG: [SSH] [email protected] cmd = test -f /etc/lsb-release && cat /etc/lsb-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/oracle-release && cat /etc/oracle-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/enterprise-release && cat /etc/enterprise-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/parallels-release && cat /etc/parallels-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/system-release && cat /etc/system-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/redhat-release && cat /etc/redhat-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/SuSE-release && cat /etc/SuSE-release
DEBUG: [SSH] [email protected] cmd = test -f /etc/arch-release
DEBUG: [SSH] [email protected] cmd = uname -r
DEBUG: [SSH] [email protected] cmd = sh -c '(sudo echo) < /dev/null'
DEBUG: [SSH] [email protected] cmd = sudo echo '[SSH] Established'
WARNING: Performing legacy client registration with the validation key at /home/myUser/.chef/org-validator.pem...
WARNING: Remove the key file or remove the 'validation_key' configuration option from your config.rb (knife.rb) to use more secure user credentials for client registration.
TRACE: Looking for bootstrap template in /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/knife-18.2.7/lib/chef/knife/bootstrap/templates
TRACE: Found bootstrap template: /opt/chef-workstation/embedded/lib/ruby/gems/3.1.0/gems/knife-18.2.7/lib/chef/knife/bootstrap/templates/chef-full.erb
Bootstrapping 10.2.128.80
DEBUG: [SSH] [email protected] cmd = sudo sh /tmp/chef_T472LE/bootstrap.sh
 [10.2.128.80] -----> Installing Chef Omnibus (stable/18)
downloading https://omnitruck.chef.io/chef/install.sh
  to file /tmp/install.sh.32304/install.sh
 [10.2.128.80] trying wget...
 [10.2.128.80] "arch" "rolling" x86_64
 [10.2.128.80] Getting information for chef stable 18 for "arch"...
 [10.2.128.80] downloading https://omnitruck.chef.io/stable/chef/metadata?v=18&p="arch"&pv="rolling"&m=x86_64
  to file /tmp/install.sh.32308/metadata.txt
 [10.2.128.80] trying wget...
 [10.2.128.80] ERROR 404
 [10.2.128.80] Omnitruck artifact does not exist for version 18 on platform "arch"

Either this means:
   - We do not support "arch"
   - We do not have an artifact for 18

 [10.2.128.80] This is often the latter case due to running a prerelease or RC version of Chef
or a gem version which was only pushed to rubygems and not omnitruck.

You may be able to set your knife[:bootstrap_version] to the most recent stable
release of Chef to fix this problem (or the most recent stable major version number).

In order to test the version parameter, adventurous users may take the Metadata URL
 [10.2.128.80] below and modify the '&v=<number>' parameter until you successfully get a URL that
does not 404 (e.g. via curl or wget).  You should be able to use '&v=11' or '&v=12'
 [10.2.128.80] successfully.

 [10.2.128.80] If you cannot fix this problem by setting the bootstrap_version, it probably means
that "arch" is not supported.
 [10.2.128.80]
Metadata URL: https://omnitruck.chef.io/stable/chef/metadata?v=18&p="arch"&pv="rolling"&m=x86_64
 [10.2.128.80] Starting the first Chef Infra Client Client run...
 [10.2.128.80] /tmp/chef_T472LE/bootstrap.sh: line 364: chef-client: command not found
ERROR: The following error occurred on 10.2.128.80:
ERROR: -----> Installing Chef Omnibus (stable/18)
     downloading https://omnitruck.chef.io/chef/install.sh
       to file /tmp/install.sh.32304/install.sh
     trying wget...
     "arch" "rolling" x86_64
     Getting information for chef stable 18 for "arch"...
     downloading https://omnitruck.chef.io/stable/chef/metadata?v=18&p="arch"&pv="rolling"&m=x86_64
       to file /tmp/install.sh.32308/metadata.txt
     trying wget...
     ERROR 404
     Omnitruck artifact does not exist for version 18 on platform "arch"

     Either this means:
        - We do not support "arch"
        - We do not have an artifact for 18

     This is often the latter case due to running a prerelease or RC version of Chef
     or a gem version which was only pushed to rubygems and not omnitruck.

     You may be able to set your knife[:bootstrap_version] to the most recent stable
     release of Chef to fix this problem (or the most recent stable major version number).

     In order to test the version parameter, adventurous users may take the Metadata URL
     below and modify the '&v=<number>' parameter until you successfully get a URL that
     does not 404 (e.g. via curl or wget).  You should be able to use '&v=11' or '&v=12'
     successfully.

     If you cannot fix this problem by setting the bootstrap_version, it probably means
     that "arch" is not supported.

     Metadata URL: https://omnitruck.chef.io/stable/chef/metadata?v=18&p="arch"&pv="rolling"&m=x86_64
     Starting the first Chef Infra Client Client run...
      /tmp/chef_T472LE/bootstrap.sh: line 364: chef-client: command not found
DEBUG: [SSH] [email protected] cmd = sudo rm -f "/tmp/chef_T472LE/bootstrap.sh"

Entendo que, como o Arch Linux não é compatível, ele não encontrará o arquivo para download no seguinte URL .

Existe alguma maneira de fazê-lo pensar que é um sistema operacional compatível? Se pudesse baixar o arquivo para uma instalação do Debian, o resto da instalação ainda funcionaria?

Estou usando CachyOS KDE (Arch Linux familiy) e tenho um problema com emoji. Existem fontes de emojis coloridos carregados no sistema, mas na caixa de notificação nem todos são coloridos. Há um exemplo na captura de tela. Este é o caso mesmo após uma nova instalação do sistema a partir do zero.

Em anexo ao tópico está uma captura de tela da fonte que uso no sistema. Por exemplo, este emoji não é colorido nas notificações "?", mas quando colo no código do Visual Studio ou outro editor, ele é colorido.

Como posso consertar isso?

KDE Plasma 5.27.6

Diz aqui que existem 5 chaves de assinatura mestre para o projeto Arch Linux. Ele também diz que desenvolvedores ativos e confiáveis ​​têm suas chaves assinadas por uma ou mais chaves mestras. E podemos ver que a chave pessoal de Pierre Schmitz é assinada pelas chaves mestras 0x77514E00, 0x7BE9892E e 0x037F4F41.

Agora, importei todas as chaves mestras do projeto Arch, incluindo 0x77514E00, 0x7BE9892E e 0x037F4F41, que, segundo o site do Arch, assinaram a chave pessoal de Pierre Schmitz.

Eu verifiquei o archlinux-x86_64.iso com o archlinux-x86_64.iso.sig. Ele disse que não foi verificado e para procurar esse ID de chave

0x3E80CA1A8B89F69CBA57D98A76A5EF9054449A5C

. Multar. Mas eu só queria verificar independentemente se a chave pessoal de Pierre Schmitz está de fato assinada pelas chaves mestras para que eu possa começar a fazer essas verificações de forma inteligente durante esta e muitas tarefas futuras.

Listei assinaturas para o ID da chave de Pierre Schmitz : Auto-assinado ok, acho que preciso receber as chaves?

Executei chaves recv no ID da chave:

eu atualizo:

E listei as chaves novamente para o ID em questão:

Isso realmente não é possível? Não é sempre ou nunca possível verificar independentemente se uma chave foi assinada por um conjunto definido de chaves mestras? Ou onde estou cometendo um erro neste procedimento de verificação?

Como podemos obter o nome do arquivo de pacote tar (no diretório do cache) a partir de um nome de pacote?

$ pacman -Q       

...

ou

$ pacman -F        

...

para a CLI correta completa

Estou usando o alacritty 0.11.0 (8dbaa0bb) no Arch.

TERMo tipo padrão é alacritty, que funciona bem (truecolors etc) para tudo, exceto emacs de terminal. Em um terminal, o emacs não mostra truecolors.

No entanto, se eu export TERM=alacritty-directentão tudo, incluindo o emacs, funcionar bem AFAICT.

Qual é a finalidade alacritty-directe quando deve ser usado?

Atualmente tenho isso em meu.zshrc

[[ "${TERM}" == "alacritty" ]] && export TERM=alacritty-direct

Após 5 dias sem atualizações, fazendo verificações diárias com pacman -Syyuuma grande quantidade de 1 GB de atualizações, por que isso acontece?

Sou novo no Arch Linux, gostaria que isso fosse apenas uma coincidência e não algo ruim.

Estou tentando instalar o Arch Linux em uma VM do Windows 11 Hyper-V. O ISO que eu uso é archlinux-2022.06.01-x86_64.iso.

Ao iniciar a VM, mostra um menu onde posso escolher entre

• Meio de instalação do Arch Linux (x86_64, UEFI)
• Meio de instalação do Arch Linux (x86_64, UEFI) com fala
• Meio de instalação do Arch Linux (x86_64, UEFI, Copiar para RAM)
• Meio de instalação do Arch Linux (x86_64, UEFI, Copy to RAM) com fala
• Escudo EFI
• Reinicialize na interface de firmware

Eu escolho o primeiro. Em seguida, a instalação trava em uma tela preta. Eu não recebo um prompt de comando. No gerenciador do Hyper-V, posso ver que a VM está usando alguma CPU (diz 8%). Deixei funcionar por 15 minutos, mas nada acontece.

Desativei a inicialização segura na VM, pois entendo que você precisa fazer isso.

Eu tenho uma VM Ubuntu que funciona bem, fwiw.

Por que trava?

Editar: Estas são as configurações do Hyper-V. É uma VM de geração 2.

Seagate Barracuda ST1000LM048

Recentemente, usei um SSD. O teste smartctl mostrou que a unidade neste sistema está excepcionalmente ocupada com pequenas gravações, então instalei este novo HDD Seagate que me parece lento. Isso é porque eu fui estragado pelas velocidades do SSD ou esta unidade está um pouco fora do lugar.

Eu verifiquei as conexões físicas SATA e elas são boas e firmes.

leituras de hdparm

  Timing buffered disk reads: 342 MB in  3.02 seconds = 113.42 MB/sec
  Timing buffered disk reads: 354 MB in  3.00 seconds = 117.94 MB/sec
  Timing buffered disk reads: 288 MB in  3.01 seconds =  95.82 MB/sec
  Timing buffered disk reads: 334 MB in  3.01 seconds = 110.84 MB/sec
  Timing buffered disk reads: 320 MB in  3.08 seconds = 104.04 MB/sec