Eu preciso executar um script a cada 64 horas. Não encontrei a resposta com cron. É possível com isso ou devo usar um loop em um script de shell?
Dada uma string composta por 0s e 1s, meu objetivo é substituir 0 por 1 e vice-versa. Exemplo:
Entrada
111111100000000000000
Saída pretendida
000000011111111111111
Tentei, sem sucesso, o seguinte sedcomando
echo '111111100000000000000' | sed -e 's/0/1/g ; s/1/0/g'
000000000000000000000
o que estou perdendo?
Adquiri uma Interface Homem-Máquina (Exor Esmart04). Rodando no Linux 3.10.12, porém este Linux é despojado e não possui um compilador C. Outro problema é o espaço em disco:
Tentei instalar o GCC nele mas não tenho espaço em disco suficiente para isso, alguém tem outras soluções ou outros compiladores C que requerem menos espaço em disco?
:>filename.txt
Por exemplo:
root@box$ dd if=/dev/zero of=file.txt count=1024 bs=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.00536175 s, 196 MB/s
root@box$ ll
total 1024
-rw-r--r-- 1 root root 1048576 Nov 15 14:40 file.txt
root@box$ :>file.txt
root@box$ ll
total 0
-rw-r--r-- 1 root root 0 Nov 15 14:40 file.txt
Isso é diferente de um rm? Ele opera mais rápido ou mais devagar do que outros meios semelhantes de zerar um arquivo ou excluí-lo?
Gostaria de remover linhas vazias do início e do final do arquivo, mas não remover linhas vazias entre as linhas não vazias no meio. Eu acho sedou awkseria a solução.
Fonte:
1:
2:
3:line1
4:
5:line2
6:
7:
8:
Resultado:
1:line1
2:
3:line2
Temos uma verificação de linha de base automatizada que gera um alerta se as permissões /etc/shadownão estiverem definidas como 000.
A equipe que recebe esses alertas começou a questionar a sanidade de 000, já que o root pode ler e escrever onde quiser (todos os arquivos são automaticamente pelo menos 600 para root) mas o root não pode executar um arquivo sem o conjunto de permissões de execução (não permissão automática de 700 arquivos para root).
Definir /etc/shadowpermissões para 000 está em várias linhas de base, por exemplo, os playbooks Ansible no repositório oficial do Red Hat GitHub (para PCI DSS, CJIS, NIST, CCE).
Existe uma história de origem por trás de por que /etc/shadowdeveria ser 000 e não, por exemplo, a funcionalidade aparentemente idêntica 600? Ou minhas suposições estão erradas sobre o quão restritivo / permissivo o Linux é para o usuário root?
Eu usei o mkfifo <file>comando para criar FIFOs nomeados, onde um processo grava no arquivo e outro processo lê do arquivo.
Agora, eu sei que o mknodcomando é capaz de criar pipes nomeados. Esses pipes nomeados são equivalentes aos FIFOs criados pelo mkfifo, ou eles têm recursos diferentes?
Na minha cópia do conda.shscript, vejo as seguintes linhas:
if [ -n "${_CE_CONDA}" ] && [ -n "${WINDIR+x}" ]; then
SYSP=$(\dirname "${CONDA_EXE}")
else
SYSP=$(\dirname "${CONDA_EXE}")
SYSP=$(\dirname "${SYSP}")
fi
Estou curioso para saber por que há uma barra invertida na frente do din dirname. Não acredito que seja necessário. Esse uso de barras invertidas também aparece em outros lugares no arquivo de origem. Existe uma razão para fazer isso que estou perdendo?
Esta é a minha configuração xrdp:
[Globals]
ini_version=1
fork=true
port=3389
use_vsock=false
tcp_nodelay=true
tcp_keepalive=true
security_layer=negotiate
crypt_level=high
certificate=
key_file=
ssl_protocols=TLSv1.2, TLSv1.3
autorun=
allow_channels=true
allow_multimon=true
bitmap_cache=true
bitmap_compression=true
bulk_compression=true
max_bpp=128
use_compression=yes
new_cursors=true
use_fastpath=both
blue=009cb5
grey=dedede
ls_top_window_bg_color=009cb5
ls_width=350
ls_height=430
ls_bg_color=dedede
ls_logo_filename=
ls_logo_x_pos=55
ls_logo_y_pos=50
ls_label_x_pos=30
ls_label_width=65
ls_input_x_pos=110
ls_input_width=210
ls_input_y_pos=220
ls_btn_ok_x_pos=142
ls_btn_ok_y_pos=370
ls_btn_ok_width=85
ls_btn_ok_height=30
ls_btn_cancel_x_pos=237
ls_btn_cancel_y_pos=370
ls_btn_cancel_width=85
ls_btn_cancel_height=30
[Logging]
LogFile=xrdp.log
LogLevel=DEBUG
EnableSyslog=true
SyslogLevel=DEBUG
[Channels]
rdpdr=true
rdpsnd=true
drdynvc=true
cliprdr=true
rail=true
xrdpvr=true
tcutils=true
[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1
[Xorg]
name=Xorg
lib=libxup.so
username=ask
password=ask
ip=127.0.0.1
port=-1
code=20
Estou tentando me conectar com mstsc a esta máquina (isto é após a reinicialização do pc, ninguém fez login):
enquanto nesta caixa de login, nenhuma desconexão acontece:
depois de colocar o login/senha corretos, recebo a tela preta primeiro e, em seguida, a janela mstsc fecha. Tentei me conectar a partir do aplicativo de conexão remota do KDE, mas também falhou da mesma maneira. xrdp.log não parece conter nada interessante:
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connecting to sesman ip 127.0.0.1 port 3350
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: sesman connect ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: sending login info to session manager, please wait...
[20190606-04:14:36] [DEBUG] return value from xrdp_mm_connect 0
[20190606-04:14:36] [INFO ] xrdp_wm_log_msg: login successful for display 10
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC started connecting
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connecting to 127.0.0.1 5910
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC tcp connected
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC security level is 2 (1 = none, 2 = standard)
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC password ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending share flag
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving server init
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name length
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC receiving name
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending pixel format
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending encodings
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending framebuffer update request
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC sending cursor
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: VNC connection complete, connected ok
[20190606-04:14:36] [DEBUG] xrdp_wm_log_msg: connected ok
[20190606-04:14:36] [DEBUG] xrdp_mm_connect_chansrv: chansrv connect successful
[20190606-04:14:36] [DEBUG] Closed socket 18 (AF_INET 127.0.0.1:47744)
[20190606-04:14:37] [DEBUG] Closed socket 20 (AF_UNIX)
[20190606-04:14:37] [DEBUG] Closed socket 12 (AF_INET 127.0.0.1:3389)
[20190606-04:14:37] [DEBUG] xrdp_mm_module_cleanup
[20190606-04:14:37] [DEBUG] VNC mod_exit
[20190606-04:14:37] [DEBUG] Closed socket 19 (AF_INET 127.0.0.1:40224)
Como posso corrigir isso?
Eu tenho um diretório com mais de 400 GiB de dados nele. Eu queria verificar se todos os arquivos podem ser lidos sem erros, então uma maneira simples que pensei foi tarem /dev/null. Mas, em vez disso, vejo o seguinte comportamento:
$ time tar cf /dev/null .
real 0m4.387s
user 0m3.462s
sys 0m0.185s
$ time tar cf - . > /dev/null
real 0m3.130s
user 0m3.091s
sys 0m0.035s
$ time tar cf - . | cat > /dev/null
^C
real 10m32.985s
user 0m1.942s
sys 0m33.764s
O terceiro comando acima foi parado à força por Ctrl+ Cdepois de já ter sido executado por um bom tempo. Além disso, enquanto os dois primeiros comandos estavam funcionando, o indicador de atividade do dispositivo de armazenamento que continha .estava quase sempre ocioso. Com o terceiro comando, o indicador fica constantemente aceso, o que significa extrema ocupação.
Então, parece que, quando taré capaz de descobrir que seu arquivo de saída é /dev/null, ou seja, quando /dev/nullé aberto diretamente para ter o identificador de arquivo no qual tarescreve, o corpo do arquivo aparece ignorado. (Adicionar vopção para tarimprimir todos os arquivos no diretório sendo tar'vermelho.)
Então eu me pergunto, por que isso é assim? É algum tipo de otimização? Se sim, então por que iria tarquerer fazer uma otimização tão duvidosa para um caso tão especial?
Estou usando o GNU tar 1.26 com glibc 2.27 no Linux 4.14.105 amd64.