SebMa's questions

Estou tentando retransmitir conexões SSH da porta 122/tcp para outro servidor na porta 22/tcp com base no FQDN.

Aqui está minha configuração HAProxy:

frontend my_ssh_frontend
    bind *:122
    mode tcp
    option tcplog
    acl my_ssh_acl hdr(host) myHostname.myDomain.com
    use_backend my_ssh_backend if my_ssh_acl

backend my_ssh_backend
    mode tcp
    server myserver1 x2.y2.z2.t2:22 check

Mas é como se a condição ACL nunca fosse verdadeira e, portanto, o tráfego não fosse roteado para o backend.

Aqui está a ssh -vvvsaída:

 ssh.exe -p 122 -l admin-media myHostname.myDomain.com -vvv 2>&1 | egrep.exe -vw "identity file|Failed to open"
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
debug2: resolving "myHostname.myDomain.com" port 122
debug2: ssh_connect_direct
debug1: Connecting to myHostname.myDomain.com [x1.y1.z1.t1] port 122.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_for_Windows_8.1
kex_exchange_identification: Connection closed by remote host

Como posso fazer isso com o HAProxy?

O servidor remoto é um sistema semelhante ao FreeBSD no qual o rsync não está instalado:

$ ssh [email protected] which rsync scp
Password:
rsync not found
/usr/local/bin/scp
$ rsync -a /ring/0/share/Archives_AudioVisuel/TEST [email protected]:/ifs/par-nas01/data/MPP/ADN_Archives/Audiovisuels/
Password:
zsh:1: command not found: rsync
rsync: connection unexpectedly closed (0 bytes received so far) [sender]
rsync error: remote command not found (code 127) at io.c(226) [sender=3.1.2]
$

Tentei adicionar -e ssh, mas recebo o mesmo erro dizendo rsyncis not found.

E se eu tentar adicionar --rsync-path=/usr/local/bin/scp, mas recebo um scp: illegal option -- -erro.

Como posso fazer um rsyncpara um servidor que só possui a scpferramenta?

Qual é a diferença entre C:\Users\Defaulte C:\Users\Default Userpastas?

PS $ & "$HOME/psh/dirsize.ps1" "C:\Users\Default"

  2.01 MiB


PS $ & "$HOME/psh/dirsize.ps1" "C:\Users\Default User"

  dir : Access to the path "C:\Users\Default User" is denied.
  At C:\Users\t2-sma\psh\dirsize.ps1:2 char:21
    + "{0:n2} MiB" -f ( ( dir $dirName -force -recurse | measure -property  ...
    +                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      + CategoryInfo          : PermissionDenied: (C:\Users\Default User:String) [Get-ChildItem], UnauthorizedAccessException
      + FullyQualifiedErrorId : DirUnauthorizedAccessError,Microsoft.PowerShell.Commands.GetChildItemCommand

  0.00 MiB

• Ambos C:\Users\Defaulte C:\Users\Default Userexistem:

  PS $ dir "C:\Users" -Force | ? Name -like 'Default*'
  
    Directory: C:\Users
  
      Mode          LastWriteTime  Length  Name
      ----          -------------  ------  ----
      d-rh--   31/05/2023   10:58          Default
      d--hsl   07/12/2019   10:30          Default User
  

  
  
• dirdiz que C:\Users\Default Useré uma junção, mas surpreendentemente o PowerShell não diz nada:

  $ dir /a "C:\Users" | findstr Default
  
    31/05/2023  09:58    <DIR>          Default
    07/12/2019  10:30    <JUNCTION>     Default User [C:\Users\Default]
  
  
  PS $ (gi "C:\Users\Default User\" -Force).LinkType
  
  

Eu criei o seguinte timer e serviço SystemD e habilitei o timer:

$ sudo install -vpm 644 ncc-record.* /usr/local/lib/systemd/system/
'ncc-record.service' -> '/usr/local/lib/systemd/system/ncc-record.service'
'ncc-record.timer' -> '/usr/local/lib/systemd/system/ncc-record.timer'
$ sudo systemctl daemon-reload
$ systemctl cat ncc-record.*
# /usr/local/lib/systemd/system/ncc-record.service
[Unit]
Description=Record the New Creation Church Live sermon
After=network-online.target

[Service]
Type=oneshot
User=sebastien
Group=sebastien
#UMask=026
ExecStart=/home/sebastien/myScripts/shl/record_NCC_Live_Then_Suspend.sh

# /usr/local/lib/systemd/system/ncc-record.timer
[Unit]
Description=Trigger the service record.service
[Timer]
OnCalendar=Sun *-*-* 11:29:30
[Install]
WantedBy=timers.target
$ sudo systemctl enable ncc-record.timer 
Created symlink /etc/systemd/system/timers.target.wants/ncc-record.timer → /usr/local/lib/systemd/system/ncc-record.timer.
$

Meu cronômetro não aparece nos cronômetros ativos:

$ systemctl list-timers | grep ncc
$

Mas mostra nos temporizadores inativos sem informações sobre os tempos NEXT, LEFT, LAST e PASSED:

$ systemctl list-timers --state=inactive | grep ncc
n/a                          n/a           n/a                          n/a           ncc-record.timer               ncc-record.service
$

Como posso consertar isso ?

Estou usando um controlador RAID PERC H730 Mini:

# lspci -d::0104 -k
02:00.0 RAID bus controller: Broadcom / LSI MegaRAID SAS-3 3108 [Invader] (rev 02)
        Subsystem: Dell PERC H730 Mini
        Kernel driver in use: megaraid_sas
        Kernel modules: megaraid_sas

e aqui estão os discos conectados ao servidor:

# lsscsi -s
[0:2:0:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sda    499GB
[0:2:1:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdb   8.00TB
[0:2:2:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdc   8.00TB
[0:2:3:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdd   8.00TB
[0:2:4:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sde   8.00TB
[0:2:5:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdf   8.00TB
[0:2:6:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdg   8.00TB
[0:2:7:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdh   8.00TB
[0:2:8:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdi   8.00TB
[0:2:9:0]    disk    DELL     PERC H730 Mini   4.28  /dev/sdj   8.00TB
[0:2:10:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdk   8.00TB
[0:2:11:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdl   8.00TB
[0:2:12:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdp   8.00TB
[0:2:13:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdm   8.00TB
[0:2:14:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdn   8.00TB
[0:2:15:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdq   8.00TB
[0:2:16:0]   disk    DELL     PERC H730 Mini   4.28  /dev/sdo    399GB

Em smartctl, pensei que o nome do dispositivo eradenoting which disk on the controller is monitored.

Mas, ao usar um controlador RAID, smartctltambém é necessário The non-negative integer N (in the range of 0 to 127 inclusive) denotes which disk on the controller is monitored.e fornece um resultado completamente diferente quando o Nvalor é diferente:

# smartctl -i /dev/sdq -d megaraid,0 -j | jq -r .model_name,.user_capacity.bytes
INTEL SSDSC2BX400G4R
400088457216
# smartctl -i /dev/sdq -d megaraid,1 -j | jq -r .model_name,.user_capacity.bytes
SEAGATE ST8000NM0075
8001563222016

Parece que usar N=0retorna o disco errado porque a capacidade não corresponde à da lsscsi -ssaída.

Como escolher o Nvalor certo com smartctl?

Eu me pergunto o que gera esses @eaDirdiretórios em todo o sistema de arquivos de compartilhamentos do Synology NAS.

Preciso limpar arquivos vazios em um Synology NAS.

É seguro remover @eaDir/*@SynoEAStreamarquivos vazios?

Ou melhor ainda, posso remover esses @eaDirdiretórios?

Eu tenho o seguinte serviço oneshot+timer:

$ systemctl cat stop_syncro.service stop_syncro.timer
# /usr/local/lib/systemd/system/stop_syncro.service
[Unit]
Description=Service d_arret de la Synchro
After=network-online.target

[Service]
Type=oneshot
User=root
ExecStart=/root/shl/RUN/stop_syncro.sh

[Install]
WantedBy=multi-user.target

# /usr/local/lib/systemd/system/stop_syncro.timer
[Unit]
Description=Timer d_arret de la Synchro
[Timer]
OnCalendar=Mon-Fri *-*-* 8:00:00
[Install]
WantedBy=timers.target

Então eu reiniciei o servidor:

$ last reboot | head -1
reboot   system boot  3.10.0-1160.71.1 Tue May 30 17:53 - 15:02  (21:09)

E parece que o serviço foi executado logo após a reinicialização

$ journalctl -u stop_syncro.service
-- Logs begin at Tue 2023-05-30 17:53:15 CEST, end at Wed 2023-05-31 14:48:17 CEST. --
May 30 17:53:26 PAR-SCAL-01 systemd[1]: Starting Service d_arret de la Synchro...
May 30 17:53:27 PAR-SCAL-01 systemd[1]: Started Service d_arret de la Synchro...
May 31 08:00:01 PAR-SCAL-01 systemd[1]: Starting Service d_arret de la Synchro...
May 31 08:00:02 PAR-SCAL-01 systemd[1]: Started Service d_arret de la Synchro...
$ 

Como evito que meu serviço oneshot seja acionado apenas às 8h, em vez de também ser iniciado após a reinicialização?

Meu cronômetro é rejeitado pelo sistema no CentOS7:

$ journalctl -u synchro_ADN_To_Scality.timer --no-pager | sed 's/^.*systemd.1.: //' | sort -u
-- Logs begin at Thu 2023-04-06 10:25:28 CEST, end at Thu 2023-05-25 12:29:08 CEST. --
synchro_ADN_To_Scality.timer lacks value setting. Refusing.
[/usr/local/lib/systemd/system/synchro_ADN_To_Scality.timer:4] Failed to parse calendar specification, ignoring: Mon..Sat *-*-* 18:00:00
$ systemctl cat synchro_ADN_To_Scality.timer
# /usr/local/lib/systemd/system/synchro_ADN_To_Scality.timer
[Unit]
Description=Lancement quotidien de la Synchro des Synology ADN vers le Ring Scality
[Timer]
OnCalendar=Mon..Sat *-*-* 18:00:00
[Install]
WantedBy=timers.target

Não vejo intervalos de datas no systemd.timemanual:

$ man systemd.time | grep -F ".."
$

Os intervalos de datas não são reconhecidos no CentOS7?

Por que o diretório $XDG_RUNTIME_DIR (/run/user/$UID) não é criado após "su - user"? :

administrateur@localhost:~$ su - test
Password:
test@localhost:~$ systemctl --user
Failed to connect to bus: $DBUS_SESSION_BUS_ADDRESS and $XDG_RUNTIME_DIR not defined (consider using --machine=<user>@.host --user to connect to bus of other user)
test@localhost:~$ ls /run/user/$UID
ls: cannot access '/run/user/1004': No such file or directory
test@localhost:~$ groups
test
test@localhost:~$
logout
administrateur@localhost:~$

EDIT0: Fazer um sudo loginctl enable-linger testmantém o /run/user/$UIDdiretório lá, mas a XDG_RUNTIME_DIRvariável ainda não está definida:

administrateur@localhost:~$ sudo loginctl enable-linger test
administrateur@localhost:~$ sudo su - test
test@localhost:~$ ls /run/user/$UID/bus
/run/user/1004/bus
test@localhost:~$ echo $XDG_RUNTIME_DIR

test@localhost:~$ 
logout
administrateur@localhost:~$

Tenho a seguinte configuração de serviço:

$ systemctl cat bluetooth
# /lib/systemd/system/bluetooth.service
[Unit]
Description=Bluetooth service
Documentation=man:bluetoothd(8)
ConditionPathIsDirectory=/sys/class/bluetooth

[Service]
Type=dbus
BusName=org.bluez
ExecStart=/usr/lib/bluetooth/bluetoothd
NotifyAccess=main
#WatchdogSec=10
#Restart=on-failure
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
LimitNPROC=1
#RestartSec=5

[Install]
WantedBy=bluetooth.target suspend.target
Alias=dbus-org.bluez.service

Adicionei o suspend.targetno WantedBy=parâmetro da [Install]seção ( man systemd.unit) para o serviço ser reiniciado ao reiniciar mas isso não funciona.

EDIT0: O serviço não é interrompido na suspensão, mas precisa ser reiniciado após a retomada porque este serviço não oferece suporte à operação de suspensão/retomada em minha configuração.

EDIT1: O suspend.targettambém deve funcionar porque de acordo com man systemd.special:

   suspend.target
       A special target unit for suspending the system. This pulls in sleep.target.

EDIT2: Parece que o comando sudo systemctl edit --full bluetoothcriou outra cópia do bluetooth.servicein /etc/systemd/system/bluetooth.serviceque se tornou diferente (de /lib/systemd/system/bluetooth.service) assim que o arquivo foi salvo.

Acabei de perceber que tinha duas versões diferentes, bluetooth.serviceentão fiquei um pouco confuso.

Como reiniciar um serviço systemd ao retomar?