Nettoyage du spam : avril 2020
Bonjour, Comme nous sommes en mai, il est désormais possible de traiter les archives du mois d'avril 2020 des listes francophones. N'oubliez bien sûr pas d'ajouter votre nom à la liste des relecteurs pour que nous sachions où nous en sommes. Détails du processus de nettoyage du spam sur : https://wiki.debian.org/I18n/FrenchSpamClean
Re: rsync bloqué sur un montage cifs
Bonsoir, Le 30/04/2020 à 21:46, Christophe a écrit : Hello, Le 30/04/2020 à 19:08, Sébastien NOBILI a écrit : Est-ce qu'un démontage "lazy" fonctionne ? umount -l /mount/point Yep, j'approuve, et si ça suffit pas : umount -f -l /mount/point Effectivement, merci, ça démonte correctement mes points de montage. Mais j'ai toujours mes processus rsync D et Z que je n'arrive pas à tuer. J'ai des processus mount et umount qui sont toujours là également, suite à des tentatives de démontage/remontage infructueux. Comment les tuer ? Samy
[resolu] Re: [testing] souris et boutons
Le jeudi 23 avril 2020 à 21:32 +0200, Étienne Mollier a écrit : > Okay, ça pourrait être, au choix: > - un problème matériel mécanique, comme l'usure d'une pièce, > (est-ce que vous avez une autre souris à portée de main pour > test ?) > - un problème dans un pilote noyaux qui serait fumeux, (est-ce > que redémarrer sur un ancien noyau change quelque chose ?) > - un problème du côté du serveur d'affichage, (est-ce que > basculer entre un environnement de bureau basé sur Xorg et > un basé sur Wayland change quelque chose ?) > > En espérant que ça aide, > Amicalement, La première hypothèse était la bonne. Bizarre quand même que ces 2 boutons qui servent le moins soient les premiers à tomber en panne mais bon ... Nouvelle souris arrivée tout refonctionne. A+ Gaëtan signature.asc Description: This is a digitally signed message part
Re: unexpected behavior of cp and mv
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=959211 On 4/30/20 3:52 PM, The Wanderer wrote: On 2020-04-30 at 15:27, Alberto Sentieri wrote: I run tcpdump while running my simple program on both stretch and buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on buster it uses SMB2 (version 2 or 3). So, the problem can be solved by adding vers=1.0 to mount.cifs options. Any version from 2.0 and above will incur in the same utimensat error. I set vers to 1.0 and it worked properly. Beware: this is a security hole. My understanding (based on experiences in my workplace) is that the SMBv1 protocol is known to be inherently, unfixably insecure, to the point that current Windows versions will not speak it unless explicitly told to in an out-of-the-way and inconvenient configuration location. I would not consider forcing the use of SMBv1 to be a satisfactory resolution, unless you can be 100% sure that nothing malicious will ever be in a position to mess around here.
Re: Met welke pdf-lezer worden pdf's geopend?
Paul van der Vlis schreef op do 30-04-2020 om 09:47 [+0200]: > Op 29-04-2020 om 23:52 schreef Dirk Ruijne: > > Paul van der Vlis schreef op wo 29-04-2020 om 21:19 [+0200]: > > > > Ik zou dit eens doen in die map: > grep -l "application/pdf" *.desktop > > Ik krijg dit lijstje: > > atril.desktop > calibre-ebook-viewer.desktop > calibre-gui.desktop > gimp.desktop > inkscape.desktop > libreoffice-draw.desktop > org.gnome.Evince.desktop > xpdf.desktop > > Dat zijn dus applicaties die PDF's kunnen openen. > > Verwijder je default applicatie maar eens, je zult zien dat een ander > dan opeens het default wordt. Maar welke, dat is vrij vaag. Dat kan > een > applicatie zijn die helemaal niet geschikt is, zoals Gimp. > Je hebt gelijk. Ik krijg dan dit lijstje: evince.desktop gimp.desktop inkscape.desktop libreoffice-draw.desktop pdfmod.desktop Dan is het weer bijzonder dat dat lijstje niet overeenkomt met het lijstje uit de opties voor het bestandtype: pdf dat je ziet in de file manager. Evince staat wel bovenaan, dat zal documentviewer zijn. Ik nam aan, dat je een soort voorkeur kon instellen bij de toepassingen voor dit bestandstype. Maar dat blijkt niet waar. Er is de mogelijkheid om de volgorde te veranderen, maar na apply springt alles weer terug in de oorspronkelijke volgorde. Als ik gimp uit de lijst met opties voor het bestandstype pdf haal dan verdwijnt hij uit de lijst die getoond wordt bij rechtsklikken op een pdf-bestand en dan kiezen voor openen met. Maar niet uit: dirk@ruijne:/usr/share/applications$ grep -l "application/pdf" *.desktop evince.desktop gimp.desktop inkscape.desktop libreoffice-draw.desktop pdfmod.desktop Maar laat maar. Het werkt. Groeten, Dirk
Re: unexpected behavior of cp and mv
Thanks for the information. I will enter a bug report asking for a fix for the last stretch available samba server. Or maybe for cifs-utils on buster side. On 4/30/20 3:52 PM, The Wanderer wrote: On 2020-04-30 at 15:27, Alberto Sentieri wrote: I run tcpdump while running my simple program on both stretch and buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on buster it uses SMB2 (version 2 or 3). So, the problem can be solved by adding vers=1.0 to mount.cifs options. Any version from 2.0 and above will incur in the same utimensat error. I set vers to 1.0 and it worked properly. Beware: this is a security hole. My understanding (based on experiences in my workplace) is that the SMBv1 protocol is known to be inherently, unfixably insecure, to the point that current Windows versions will not speak it unless explicitly told to in an out-of-the-way and inconvenient configuration location. I would not consider forcing the use of SMBv1 to be a satisfactory resolution, unless you can be 100% sure that nothing malicious will ever be in a position to mess around here.
Re: rsync bloqué sur un montage cifs
Hello, Le 30/04/2020 à 19:08, Sébastien NOBILI a écrit : Le 2020-04-30 18:40, Samy Mezani a écrit : L'accès à ce montage est désormais bloqué : - ls destination1 n'aboutit pas (ne me rend pas le prompt) - umount destination1 fait de même Ça explique aussi les rsync qui s'empilent et ne peuvent pas être tués. Est-ce qu'un démontage "lazy" fonctionne ? umount -l /mount/point Yep, j'approuve, et si ça suffit pas : umount -f -l /mount/point Ca m'a sorti de quelques situations similaires avec des montages NFS. (j'ignorais par contre que SMB/CIFS était sujet à ce genre de problèmes). Christophe.
Re: unexpected behavior of cp and mv
On 2020-04-30 at 15:27, Alberto Sentieri wrote: > I run tcpdump while running my simple program on both stretch and > buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while > on buster it uses SMB2 (version 2 or 3). > > So, the problem can be solved by adding vers=1.0 to mount.cifs > options. Any version from 2.0 and above will incur in the same > utimensat error. I set vers to 1.0 and it worked properly. Beware: this is a security hole. My understanding (based on experiences in my workplace) is that the SMBv1 protocol is known to be inherently, unfixably insecure, to the point that current Windows versions will not speak it unless explicitly told to in an out-of-the-way and inconvenient configuration location. I would not consider forcing the use of SMBv1 to be a satisfactory resolution, unless you can be 100% sure that nothing malicious will ever be in a position to mess around here. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Re: unexpected behavior of cp and mv
I run tcpdump while running my simple program on both stretch and
buster. On stretch, x2 uses SMB (version 1, I guess) protocol, while on
buster it uses SMB2 (version 2 or 3).
So, the problem can be solved by adding vers=1.0 to mount.cifs options.
Any version from 2.0 and above will incur in the same utimensat error. I
set vers to 1.0 and it worked properly.
While using SMB2, I can also see FILE_INFO/SMB2_FILE_BASIC_INFO on
buster as a result of utimensat, so something is being sent to the samba
server.
The question to be answered now is if this is a problem on buster side,
or or on samba stretch side. The later has all updates.
On 4/30/20 1:32 PM, Thomas Schmitt wrote:
Hi,
Alberto Sentieri wrote:
ls -ls "${NAME}"
Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
[...]
I run the same binary and script on my debian stretch workstation,
and got
4 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
It is quite remarkable that the SMB file is reported to use 1024 blocks
for storing 10 bytes.
-
I am still not convinced that SYS_utimensat is to blame.
What do you get if you sleep for 3 seconds before performing it ?
If still the file timestamp changes with that sleep:
What happens if you close the fd without calling utimensat and
re-open the file for applying utimensat only then ?
(What if you let sleep between between close and re-open ?)
Have a nice day :)
Thomas
Notification of Irregular Card_Activities
https://towardsdatascience.acemlnc.com/lt.php?s=a6917ed3c256e4614beda6c1e5d47f37=3A5A1A6 _ Sent to debian-user@lists.debian.org Unsubscribe: http://towardsdatascience.acemlnc.com/proc.php?nl=1=3=5=a6917ed3c256e4614beda6c1e5d47f37=unsub AEX, 121 Leffler Ln, Palm Beach, FL 32908, United States
Re: unexpected behavior of cp and mv
1 second, 3 seconds or 10 minutes have the same result.
About the 1024 1K-blocks, if one checks the file size on the samba
server using the same command, the return will be:
4 -rwxrw-r-- 1 root cifsusers 10 Feb 5 2017 test2.txt
So, it is using only 4Kbytes on the server. I have no idea why smb
interface always reports 1Mbyte. By the way, I have seen this behavior
for many years. stat (on the workstation) also reports the same (2048
512-byte blocks).
I will do the tests you suggested later. I am also thinking about trying
a flush before utimensat. None of this, however, happens in cp.
It may not be utimensat. Between the kernel and the smb, there is a cifs
package (the driver) which could be doing it wrong. Both the kernel and
cifs package are different between the two workstations.
Thanks,
Alberto
On 4/30/20 1:32 PM, Thomas Schmitt wrote:
Hi,
Alberto Sentieri wrote:
ls -ls "${NAME}"
Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
[...]
I run the same binary and script on my debian stretch workstation, and got
4 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
It is quite remarkable that the SMB file is reported to use 1024 blocks
for storing 10 bytes.
-
I am still not convinced that SYS_utimensat is to blame.
What do you get if you sleep for 3 seconds before performing it ?
If still the file timestamp changes with that sleep:
What happens if you close the fd without calling utimensat and
re-open the file for applying utimensat only then ?
(What if you let sleep between between close and re-open ?)
Have a nice day :)
Thomas
Re: unexpected behavior of cp and mv
On Thu 30 Apr 2020 at 12:46:26 (-0400), Alberto Sentieri wrote:
> Apparently there is something wrong with the debian stretch utimensat
> system call, or with its interaction with cifs. It works as expected
> when the destination file is on a ext4 file system, but it does not
> work when the destination file is on a SMB file system.
>
> I wrote a simple C program, which I compiled with .
>
> On my debian buster workstation, I run the program using a script, which is:
>
> #!/bin/bash
> NAME='/mnt/u1/rw/receipt/test2.txt'
> rm -f "${NAME}"
> ls -ls "${NAME}"
> /mnt/1g/home/u1/data/cp-pi/x2 "${NAME}"
> ls -ls "${NAME}"
> sleep 1
> ls -ls "${NAME}"
>
> Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
>
> $ ./do2.sh
> ls: cannot access '/mnt/u1/rw/receipt/test2.txt': No such file or directory
> 0 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
> 1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
>
> As you can see, the time stamp changes after one second.
Perhaps it's more important that the time changes after the filesystem
has allocated some space for it.
(Repeat: I'm not familiar with cifs/smb protocols and filesystems.)
Cheers,
David.
RTL8187SE driver (I think) problem
I recently upgraded my Advent notebook from Debian 9 to 10 at which
point the wifi card, an RTL8187SE using the rtl818x_pci driver, stopped
working properly and no longer connects to the router while a wired
connection still works. Two other laptops, an HP Pavilion and an
ancient IBM T42, have no problems continuing to connect wirelessly
to the same router after the same upgrade.
For debugging purposes I switched the connection to a second ("Guest")
wifi network on a different MAC address (same router) and temporarily
disabled encryption to try and minimize variables but the connection
still failed. At boot dmesg shows the following:
Note:
c4:04:15:df:a2:41 is the correct router and the reference to RTL8201CP
is the currently unconnected ethernet port.
[ 89.982800] ieee80211 phy0: RTL8225-SE version not-D
[ 90.392735] ieee80211 phy0: NO Xtal cal
[ 90.476201] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[ 90.832650] RTL8201CP Ethernet r8169-100:00: attached PHY driver
[RTL8201CP Ethernet] (mii_bus:phy_addr=r8169-100:00, irq=IGNORE)
[ 90.931928] IPv6: ADDRCONF(NETDEV_UP): enp1s0: link is not ready
[ 91.618779] ieee80211 phy0: RTL8225-SE version not-D
[ 92.028739] ieee80211 phy0: NO Xtal cal
[ 92.112008] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
[ 95.711844] wlp2s0: authenticate with c4:04:15:df:a2:41
[ 95.815919] wlp2s0: send auth to c4:04:15:df:a2:41 (try 1/3)
[ 95.817858] wlp2s0: authenticated
[ 95.819729] wlp2s0: associate with c4:04:15:df:a2:41 (try 1/3)
[ 95.822393] wlp2s0: RX AssocResp from c4:04:15:df:a2:41 (capab=0x401
status=0 aid=1)
[ 95.822511] wlp2s0: associated
[ 95.822677] IPv6: ADDRCONF(NETDEV_CHANGE): wlp2s0: link becomes
ready
[ 96.116503] wlp2s0: deauthenticating from c4:04:15:df:a2:41 by local
choice (Reason: 3=DEAUTH_LEAVING)
[ 96.634772] ieee80211 phy0: RTL8225-SE version not-D
[ 97.044724] ieee80211 phy0: NO Xtal cal
[ 97.128054] IPv6: ADDRCONF(NETDEV_UP): wlp2s0: link is not ready
Repeated attempts to connect give the same output barring the IPv6
references.
As I know next to nothing about this wifi driver and the documentation is
unhepful, can anybody help by translating the dmesg output into useful
advice for resolving this? I'm particularly confused by the deauthenticating
from c4:04:15:df:a2:41 by local choice (Reason: 3=DEAUTH_LEAVING) line.
Regards
Joe
--
You'd think with all the ex-cons in this company we'd have at least
one car thief...
-- Afterburner's quotes file
Re: unexpected behavior of cp and mv
Hi,
Alberto Sentieri wrote:
> ls -ls "${NAME}"
> Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
> 1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
> [...]
> I run the same binary and script on my debian stretch workstation, and got
> 4 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
It is quite remarkable that the SMB file is reported to use 1024 blocks
for storing 10 bytes.
-
I am still not convinced that SYS_utimensat is to blame.
What do you get if you sleep for 3 seconds before performing it ?
If still the file timestamp changes with that sleep:
What happens if you close the fd without calling utimensat and
re-open the file for applying utimensat only then ?
(What if you let sleep between between close and re-open ?)
Have a nice day :)
Thomas
Re: rsync bloqué sur un montage cifs
Le 2020-04-30 18:40, Samy Mezani a écrit : L'accès à ce montage est désormais bloqué : - ls destination1 n'aboutit pas (ne me rend pas le prompt) - umount destination1 fait de même Ça explique aussi les rsync qui s'empilent et ne peuvent pas être tués. Est-ce qu'un démontage "lazy" fonctionne ? umount -l /mount/point Sébastien
Re: unexpected behavior of cp and mv
Apparently there is something wrong with the debian stretch utimensat
system call, or with its interaction with cifs. It works as expected
when the destination file is on a ext4 file system, but it does not work
when the destination file is on a SMB file system.
I wrote a simple C program, which I compiled with .
On my debian buster workstation, I run the program using a script, which is:
#!/bin/bash
NAME='/mnt/u1/rw/receipt/test2.txt'
rm -f "${NAME}"
ls -ls "${NAME}"
/mnt/1g/home/u1/data/cp-pi/x2 "${NAME}"
ls -ls "${NAME}"
sleep 1
ls -ls "${NAME}"
Note that the /mnt/u1/rw/receipt is a SMB folder. I got this result:
$ ./do2.sh
ls: cannot access '/mnt/u1/rw/receipt/test2.txt': No such file or directory
0 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
1024 -rwxr-xr-x 1 u1 u1 10 Apr 30 12:20 /mnt/u1/rw/receipt/test2.txt
As you can see, the time stamp changes after one second.
This is the C code for x2.
#include
#include
#include
#include
#include
#include
#include
static char *data = "test data\n";
static struct timespec timestamps [2] = {
{ 1588174263, 908624390 },
{ 1486350336, 481422339 }
};
int main (int argc, char **argv)
{
int fd;
if (argc > 1) {
fd = openat (AT_FDCWD, argv [1], O_WRONLY|O_CREAT, 0666);
if (fd >= 0) {
write (fd, data, strlen (data));
/* do not use glibc utimensat directly, it does not allow
NULL as a second argument */
syscall (SYS_utimensat, fd, NULL, timestamps, 0);
close (fd);
return 0;
}
}
printf ("something went wrong\n");
return 0;
}
About my buster workstation:
# cat /proc/version;dpkg -l |grep cifs
Linux version 4.19.0-8-amd64 (debian-ker...@lists.debian.org) (gcc
version 8.3.0 (Debian 8.3.0-6)) #1 SMP Debian 4.19.98-1+deb10u1 (2020-04-27)
ii cifs-utils 2:6.8-2 amd64 Common Internet File System utilities
I run the same binary and script on my debian stretch workstation, and
got this:
$ ./do2.sh
ls: cannot access '/mnt/u1/rw/receipt/test2.txt': No such file or directory
0 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
4 -rwxr-xr-x 1 u1 u1 10 Feb 5 2017 /mnt/u1/rw/receipt/test2.txt
$ cat /proc/version
Linux version 4.9.0-12-amd64 (debian-ker...@lists.debian.org) (gcc
version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian
4.9.210-1 (2020-01-20)
# dpkg -l |grep cifs
ii cifs-utils 2:6.7-1 amd64 Common Internet File System utilities
I run the C program above, using the same binary, and got two different
behaviors.
Can anyone help me with this?
On 4/29/20 5:31 PM, Thomas Schmitt wrote:
Hi,
assumed that the success of "touch" indicates that utimensat(2) works
fine, i would pick the failed fsetxattr(2) as next suspect.
Does this set the timestamps despite failing ?
setfattr -n user.test_name -v test_value /mnt/u1/rw/receipt/u1.crontab
(I expect an "Operation not supported" error as in strace.
If it succeeds against our will, try -n "test_name", without prefix
"user.".)
Alberto Sentieri wrote:
So, the cp behavior on debian stretch and buster seems to be the same.
But the implementation of the system calls is not.
touch does the trick of dup2 and close, before calling utimensat.
Hm. To verify suchtheories you will have to create a C program which
uses the traced system calls and by which you can test variations.
Quite interesting would be to inquire the file timestamps immediately
after utimensat() in order to learn whether it gets into effect at
least for a short time.
Have a nice day :)
Thomas
rsync bloqué sur un montage cifs
Bonjour, J'effectue quotidiennement des sauvegardes automatiques d'un répertoire sur un montage cifs avec rsync (2 répertoires sur un NAS nommés ci-après destination1 et destination2). Or l'accès à ce partage a dû être interrompu il y a quelques jours. dmesg | grep -i cifs [928596.483038] CIFS VFS: sends on sock eabab429 stuck for 15 seconds [928596.483091] CIFS VFS: Error -11 sending data on socket to server [928611.842812] CIFS VFS: sends on sock eabab429 stuck for 15 seconds [928611.842859] CIFS VFS: Error -11 sending data on socket to server [928627.202640] CIFS VFS: sends on sock eabab429 stuck for 15 seconds [928627.202690] CIFS VFS: Error -11 sending data on socket to server [928642.562396] CIFS VFS: sends on sock eabab429 stuck for 15 seconds [928642.562443] CIFS VFS: Error -11 sending data on socket to server [928693.800067] CIFS VFS: cifs_invalidate_mapping: could not invalidate inode 32ccb70f [2340379.438596] CIFS VFS: Server 192.168.1.3 has not responded in 180 seconds. Reconnecting... [2340380.462594] CIFS VFS: Server 192.168.1.3 has not responded in 180 seconds. Reconnecting... [2340380.462596] CIFS VFS: Server 192.168.1.3 has not responded in 180 seconds. Reconnecting... [2340380.462695] CIFS VFS: Server 192.168.1.3 has not responded in 180 seconds. Reconnecting... [2600595.771503] CIFS VFS: Close unmatched open Depuis, rsync est bloqué et il me crée chaque jour de nouveaux processus qui restent bloqués ! J'ai tenté de tuer ces processus de façon assez brutale : kill $(pgrep -f rsync) # pas d'effet puis kill -9 $(pgrep -f rsync) # idem Je me retrouve encore avec tous ces processus : 1199 ?D 0:06 rsync [-mes_paramètres source2 destination2] 1200 ?Z 0:00 [rsync] 3372 ?D 0:01 rsync [-mes_paramètres source2 destination2] 3373 ?Z 0:00 [rsync] 5278 ?D 0:00 rsync [-mes_paramètres source1 destination1] 5279 ?Z 0:00 [rsync] 7142 ?D 0:11 rsync [-mes_paramètres source2 destination2] 7143 ?Z 0:00 [rsync] 8670 ?D 19:06 rsync [-mes_paramètres source2 destination2] 8671 ?Z 0:03 [rsync] 10401 ?D 0:29 rsync [-mes_paramètres source2 destination2] 10402 ?Z 0:01 [rsync] 18307 ?D 0:02 rsync [-mes_paramètres source1 destination1] 18308 ?Z 0:00 [rsync] 19543 ?D 9:59 rsync [-mes_paramètres source2 destination2] 19544 ?Z 0:02 [rsync] 22885 ?D 0:00 rsync [-mes_paramètres source1 destination1] 22886 ?Z 0:00 [rsync] 25231 ?D 0:00 rsync [-mes_paramètres source1 destination1] 25232 ?Z 0:00 [rsync] 26455 ?D 0:00 rsync [-mes_paramètres source1 destination1] 26456 ?Z 0:00 [rsync] 26832 ?D 0:00 rsync [-mes_paramètres source1 destination1] 26833 ?Z 0:00 [rsync] 30054 ?D 0:40 rsync [-mes_paramètres source2 destination2] 30055 ?Z 0:02 [rsync] 30422 ?D 0:19 rsync [-mes_paramètres source2 destination2] 30423 ?Z 0:01 [rsync] 31032 ?D 0:04 rsync [-mes_paramètres source2 destination2] 31033 ?Z 0:00 [rsync] L'accès à ce montage est désormais bloqué : - ls destination1 n'aboutit pas (ne me rend pas le prompt) - umount destination1 fait de même Je ne peux pas redémarrer ce poste car il s'agit d'un serveur situé dans un local inaccessible pour l'instant et un petit souci matériel au démarrage oblige à le redémarrer sur place une 2e fois (je perds l'accès SSH). Comment arrêter rsync et essayer de démonter/remonter ce partage ? Merci Samy
Re: fail2ban regex
Bonjour, Je ne sais pas si cela correspond à ce que vous cherchez mais ici pour les serveurs sensibles nous nous appuyons en complément de Fail2ban qui ne banni que les IP de façon temporaires 2 ajouts : Un outil de bannissement « définitif » pour ceux qui insistent lourdement « multiban » répétés, basé sur l’analyse des logs de Fail2ban. Vous pouvez le trouver sur l’URL suivante : https://www.cybernaute.ch/bannir-definitivement-ip-bannies-frequemment-fail2ban/ Mais cela ne suffisant pas car les réseaux servant à beaucoup d’attaques permettent le changement d’IP, nous ajoutons des règles « ipset » nourries par des RBL qui bloquent même certains réseaux connus pour leurs pratiques douteuses. La solution simple est basée sur 3 ou 4 sites (https://blognote32.net/iptables-ip-blacklist/) Vous pouvez aussi aller voir sur https://iplists.firehol.org/#aboutCollapseThree… Cordialement > Le 30 avr. 2020 à 12:01, BERTRAND Joël a écrit : > > Nisar JAGABAR a écrit : >> >> Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te >> permets de le faire, regarde la sortie de 'fail2ban-client --help' ou >> son man : >> bash# fail2ban-client set banip >> >> Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un >> bash# fail2ban-client status >> >> Pour les IP déjà bannis sur un JAIL particulier : >> bash# fail2ban-client status > > Parce que le type est borné, que ça fait des jours que ça dure et que > l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et > j'ai autre chose à faire que de surveiller /var/log/syslog. > > JKB > -- Pierre Malard « on ne risque rien à livrer le secret professionnel car on ne livre pas la façon de s’en servir » Jean Cocteau - « Le secret professionnel » - 1922 |\ _,,,---,,_ /,`.-'`'-. ;-;;,_ |,4- ) )-,_. ,\ ( `'-' '---''(_/--' `-'\_) πr perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\ ( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_): 24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print' - --> Ce message n’engage que son auteur <-- signature.asc Description: Message signed with OpenPGP
Re: problème de console
Bonsoir, Que dit systemctl status getty@tty1.services Si inactive, peut-être qu'un systemctl enable getty@tty1.services aidera. Steve Le 30-04-2020, à 12:17:21 +0200, Kohler Gerard a écrit : bonjour, je suis sous Bullseyes depuis quelques temps j'ai un nouveau comportement des consoles de mon système Debian la console n°1 affiche les messages d'initialisation du système et est inaccessible à la connexion . habituellement je pouvais me connecter dessus après le démarrage du système. je n'ai pas trouvé d'erreur dans les logs. Est-ce un comportement normal ?
Re: problème de console
bon, ça ne doit plus être le cas car je n'ai pas de fichier /etc/inittab merci Le 30/04/2020 à 15:42, Sébastien NOBILI a écrit : Bonjour, Le 2020-04-30 12:17, Kohler Gerard a écrit : depuis quelques temps j'ai un nouveau comportement des consoles de mon système Debian la console n°1 affiche les messages d'initialisation du système et est inaccessible à la connexion . Je ne sais pas si c'est toujours d'actualité depuis le passage à Systemd, mais historiquement le comportement des TTY se configurait dans le fichier `/etc/inittab` (toujours présent ici, sous Buster). C'est ce bloc-là : 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6 Sébastien
Re: Problème de rafraichissement de Firefox avec Gnome 3.36
- Mail original - > De: "Sébastien Dinot" > À: "ML Debian User French" > Envoyé: Jeudi 30 Avril 2020 15:51:24 > Objet: Re: Problème de rafraichissement de Firefox avec Gnome 3.36 > > Sébastien Dinot a écrit : > > À défaut de solution, s'il y a sur cette liste des utilisateurs de > Debian testing (Bulleyes) et de Firefox ayant basculé sur Gnome 3.36, > je > serais heureux de savoir s'ils rencontrent le même problème. > > En effet, je suis vraiment surpris de ne trouver aucune trace de ce > problème fort pénible sur le net et comme mes machines sont en > testing > et actualisées chaque jour depuis plusieurs années, je me demande si > le > problème ne serait pas imputable à l'accumulation de « scories », > désormais obsolètes, mais perturbant le bon fonctionnement du > système. > > Je vous en remercie par avance, > > Sébastien > bonjour, pourrais tu lancer firefox à partir du terminal en mode safe ? /usr/bin/firefox -safe-mode et installer "profile switcher" : https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles?redirectlocale=en-US=profile-manager-create-and-remove-firefox-profiles merci pour ton aimable attention bien à toi bernard
Re: Problème de rafraichissement de Firefox avec Gnome 3.36
Thu, 30 Apr 2020 15:51:24 +0200 Sébastien Dinot écrivait : salut Sébastien, > Sébastien Dinot a écrit : > > Et question subsidiaire : suis-je le seul à rencontrer ce problème ou > > à utiliser encore Firefox ? > > À défaut de solution, s'il y a sur cette liste des utilisateurs de > Debian testing (Bulleyes) et de Firefox ayant basculé sur Gnome 3.36, je > serais heureux de savoir s'ils rencontrent le même problème. J'utilise un système comparable, Bulleyes/unstable + FF 75 + Gnome 3.36 + Wayland. Aucun soucis. Pour être sûr que Firefox utilise Wayland, tu as vérifié grâce à la commande xlsclients ? Toutes les apllications ne l'utilisent pas. > En effet, je suis vraiment surpris de ne trouver aucune trace de ce > problème fort pénible sur le net et comme mes machines sont en testing > et actualisées chaque jour depuis plusieurs années, je me demande si le > problème ne serait pas imputable à l'accumulation de « scories », > désormais obsolètes, mais perturbant le bon fonctionnement du système. Je ne peux que te conseiller de renommer ton profile et de redémarrer FF avec un profile neuf. Bien que j'ai lu que tu avais déjà essayer en safe mode. Autre solution avec FF, c'es l'option "Réparer Firefox..." sur la page about:support > Je vous en remercie par avance, Bonne chance. > Sébastien Jean-Marc https://6jf.be/keys/ED863AD1.txt pgpS9LGyVkJvk.pgp Description: PGP signature
Re: Output from date command defaults to 12-hour in Buster.
Greg Wooledge (12020-04-30): > For the first part, you want LC_NUMERIC=C. Damn right I want LC_NUMERIC=C. And I want LC_COLLATE=C. And I want LC_NUMERIC=C, and LC_TIME=C. And I also want LC_WHATEVER_THE_HECK_THEY_WILL_INVENT_NEXT=C too. I want LC_EVERYTHING=C except LC_CTYPE. And everybody who works with command-line tools should want the same, because these things were ugly mistakes with way more drawbacks than benefits. > For the second part, what you're asking for is sometimes called > "rational ranges", or "rational range interpretation". This is the > notion that, for specific range expressions like '[a-z]' within a > regular expression or glob, the software will assume you want to > match only '[[:lower:]]', rather than doing what you actually said. > > The idea behind this is based on the (probably accurate) belief that > most people who write [a-z] or [A-Z] in their scripts wanted the > LC_COLLATE=C (or 1980s) meaning of the range, not the meaning of the > range in modern times. Thus, it's a sort of safety net strung below > the novice programmer, to catch them when they fall. > > Since this is not how systems currently behave, however, what you need > to do in your script is write the expression correctly. For your > example, I believe that would be [[:xdigit:]]. Or if you really do > mean to restrict it to lower-case 'a' through 'f', retain what you > have, but set LC_COLLATE=C first. > > I haven't seen rational range interpretation discussion that covers > '[a-f]', but I haven't been following it closely. I am very aware of the pros of cons of localized collation. The thing that was incredibly stupid was to change the semantic of something as fundamental as regular expressions. The correct way to introduce localized alphabetical order in regular expression would have been to introduce a new notation for it, not to hijack something that was already used. Since this ugly mistake has been made, the only sane course of action is to let locales to their C setting. Which is exactly what I do, and I am very fine with it. And I can laugh by myself every time somebody comes complaining that the output of a command is ugly because it did not consider localization would break alignment, or that a script is broken because the matching of a regexp has been altered. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: unexpected behavior of cp and mv
Thanks. By any chance is there a cifs specialist watching this thread? Apparently the timestamp is initially correct but it changes after a while. Does anyone knows why? Is there a worker finishing the file copy, which could be creating this effect? I wrote the following script to repeat my tests: #!/bin/bash rm -f /mnt/u1/rw/receipt/u1.crontab /bin/stat /mnt/u1/rw/receipt/u1.crontab /bin/cp -pi /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/ ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab /bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab sleep 1 ls -ls /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab /bin/stat /mnt/1g/home/u1/data/u1.crontab /mnt/u1/rw/receipt/u1.crontab The result is this: $ ./do_it.sh /bin/stat: cannot stat '/mnt/u1/rw/receipt/u1.crontab': No such file or directory 4 -rw-r--r-- 1 u1 u1 54 Feb 5 2017 /mnt/1g/home/u1/data/u1.crontab 0 -rwxr-xr-x 1 u1 u1 54 Feb 5 2017 /mnt/u1/rw/receipt/u1.crontab File: /mnt/1g/home/u1/data/u1.crontab Size: 54 Blocks: 8 IO Block: 4096 regular file Device: 831h/2097d Inode: 58721601 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ u1) Gid: ( 1000/ u1) Access: 2020-04-29 11:31:03.908624390 -0400 Modify: 2017-02-05 22:05:36.481422339 -0500 Change: 2017-02-05 22:05:36.581420492 -0500 Birth: - File: /mnt/u1/rw/receipt/u1.crontab Size: 54 Blocks: 0 IO Block: 16384 regular file Device: 2ch/44d Inode: 75374568 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 1000/ u1) Gid: ( 1000/ u1) Access: 2020-04-29 11:31:03.908624300 -0400 Modify: 2017-02-05 22:05:36.481422300 -0500 Change: 2020-04-30 10:04:07.613793700 -0400 Birth: - 4 -rw-r--r-- 1 u1 u1 54 Feb 5 2017 /mnt/1g/home/u1/data/u1.crontab 1024 -rwxr-xr-x 1 u1 u1 54 Apr 30 10:04 /mnt/u1/rw/receipt/u1.crontab File: /mnt/1g/home/u1/data/u1.crontab Size: 54 Blocks: 8 IO Block: 4096 regular file Device: 831h/2097d Inode: 58721601 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 1000/ u1) Gid: ( 1000/ u1) Access: 2020-04-29 11:31:03.908624390 -0400 Modify: 2017-02-05 22:05:36.481422339 -0500 Change: 2017-02-05 22:05:36.581420492 -0500 Birth: - File: /mnt/u1/rw/receipt/u1.crontab Size: 54 Blocks: 2048 IO Block: 16384 regular file Device: 2ch/44d Inode: 75374568 Links: 1 Access: (0755/-rwxr-xr-x) Uid: ( 1000/ u1) Gid: ( 1000/ u1) Access: 2020-04-29 11:31:03.908624300 -0400 Modify: 2020-04-30 10:04:07.611931500 -0400 Change: 2020-04-30 10:04:07.611931500 -0400 Birth: - On 4/30/20 6:39 AM, Thomas Schmitt wrote: Hi, Alberto Sentieri wrote: I tried setfattr as you suggested with "user" and without "user". Both failed with "Operation not supported" and none of them changed the timestamp. This only leaves the idea to mimick the strace of cp -p in an own C program to see whether utimensat() has the desired effect and whether following calls spoil it. Maybe it is necessary to really create a new file and to write some realistic amount of data to it in order to set up the conditions for the problem. The code of cp.c and copy.c in https://sources.debian.org/src/coreutils/8.30-3/src/ looks not overly self-contained. So it might be difficult to get a debuggable version of cp, if not Debian package development magic can produce it. Have a nice day :) Thomas
Re: bug report
On Thu, 30 Apr 2020 15:13:29 +0300 deuxb...@gmail.com wrote: > hello, > i would like to report a bug on Debian. > fresh install on my system (Chuwi minibook) - trying to shutdown causes > reboot (windows works without a problem). Thank you! Please use the reportbug' tool: https://www.debian.org/Bugs/Reporting Celejar
Re: Problème de rafraichissement de Firefox avec Gnome 3.36
Sébastien Dinot a écrit : > Et question subsidiaire : suis-je le seul à rencontrer ce problème ou > à utiliser encore Firefox ? À défaut de solution, s'il y a sur cette liste des utilisateurs de Debian testing (Bulleyes) et de Firefox ayant basculé sur Gnome 3.36, je serais heureux de savoir s'ils rencontrent le même problème. En effet, je suis vraiment surpris de ne trouver aucune trace de ce problème fort pénible sur le net et comme mes machines sont en testing et actualisées chaque jour depuis plusieurs années, je me demande si le problème ne serait pas imputable à l'accumulation de « scories », désormais obsolètes, mais perturbant le bon fonctionnement du système. Je vous en remercie par avance, Sébastien -- Sébastien Dinot, sebastien.di...@free.fr http://www.palabritudes.net/ Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Re: problème de console
Bonjour, Le 2020-04-30 12:17, Kohler Gerard a écrit : depuis quelques temps j'ai un nouveau comportement des consoles de mon système Debian la console n°1 affiche les messages d'initialisation du système et est inaccessible à la connexion . Je ne sais pas si c'est toujours d'actualité depuis le passage à Systemd, mais historiquement le comportement des TTY se configurait dans le fichier `/etc/inittab` (toujours présent ici, sous Buster). C'est ce bloc-là : 1:2345:respawn:/sbin/getty 38400 tty1 2:23:respawn:/sbin/getty 38400 tty2 3:23:respawn:/sbin/getty 38400 tty3 4:23:respawn:/sbin/getty 38400 tty4 5:23:respawn:/sbin/getty 38400 tty5 6:23:respawn:/sbin/getty 38400 tty6 Sébastien
bug report
hello, i would like to report a bug on Debian. fresh install on my system (Chuwi minibook) - trying to shutdown causes reboot (windows works without a problem). thank you
Re: acces au lecteur cdrom ? quel /dev/????
En plein dans le 1000 !!! Merci à vous 2 pour vos conseils ! Le 30/04/2020 à 12:46, Raphaël POITEVIN a écrit : > Petrusko writes: >> Je me demande comment accéder à mon lecteur de CDROM/DVD, à partir >> duquel j'aimerais créer une image .iso du disque qu'il contient. >> En voyant plusieurs tutos, je n'arrive pas à trouver dans quel >> /dev/x il se trouve ! (ou alors j'ai un problème hardware, possible >> aussi!) > /dev/sr0 en général et des liens symboliques /dev/cdrom /dev/dvd
Re: Output from date command defaults to 12-hour in Buster.
> On Mi, 29 apr 20, 19:18:14, Nicolas George wrote: > > I live in the rest of the world, and I do NOT want my numbers to have > > commas in them instead of decimal points, nor do I want [0-9a-f] to > > match "ça" and "fée". For the first part, you want LC_NUMERIC=C. For the second part, what you're asking for is sometimes called "rational ranges", or "rational range interpretation". This is the notion that, for specific range expressions like '[a-z]' within a regular expression or glob, the software will assume you want to match only '[[:lower:]]', rather than doing what you actually said. The idea behind this is based on the (probably accurate) belief that most people who write [a-z] or [A-Z] in their scripts wanted the LC_COLLATE=C (or 1980s) meaning of the range, not the meaning of the range in modern times. Thus, it's a sort of safety net strung below the novice programmer, to catch them when they fall. Since this is not how systems currently behave, however, what you need to do in your script is write the expression correctly. For your example, I believe that would be [[:xdigit:]]. Or if you really do mean to restrict it to lower-case 'a' through 'f', retain what you have, but set LC_COLLATE=C first. I haven't seen rational range interpretation discussion that covers '[a-f]', but I haven't been following it closely.
Resolu: Erreur non bloquante lors du Boot
Le 30/04/2020 à 12:53, informatique a écrit : Le 30/04/2020 à 12:12, steve a écrit : Bonjour François-Marie, Que donne systemctl status systemd-sysusers.service ceci systemd-sysusers.service - Create System Users Loaded: loaded (/lib/systemd/system/systemd-sysusers.service; static; vendor Active: failed (Result: exit-code) since Thu 2020-04-30 12:42:19 CEST; 6min a Docs: man:sysusers.d(5) man:systemd-sysusers.service(8) Main PID: 586 (code=exited, status=1/FAILURE) avril 30 12:42:19 debian-0 systemd[1]: Starting Create System Users... avril 30 12:42:19 debian-0 systemd-sysusers[586]: Creating group systemd-coredum avril 30 12:42:19 debian-0 systemd-sysusers[586]: Creating user systemd-coredump avril 30 12:42:19 debian-0 systemd-sysusers[586]: Failed to write files: Invalid avril 30 12:42:19 debian-0 systemd[1]: systemd-sysusers.service: Main process ex avril 30 12:42:19 debian-0 systemd[1]: systemd-sysusers.service: Failed with res avril 30 12:42:19 debian-0 systemd[1]: Failed to start Create System Users. Et en root, que donne grpck -r 'utilisateur' is a member of the 'dialout' group in /etc/group but not in /etc/gshadow 'utilisateur' is a member of the 'plugdev' group in /etc/group but not in /etc/gshadow Steve Le jeudi 30 avril 2020, informatique a écrit : Bonjour, j'ai cette erreur lors du Boot de ma machine : Failed to start Create System Users sans savoir d'ou elle vient. Merci -- François-Marie Bonjout donc la réponse est un problème des utilisateurs avec le groupe gshadow ? Merci Bonjour résolu avec un sudo grpconv merci à Steve -- François-Marie
Re: Erreur non bloquante lors du Boot
Le 30/04/2020 à 12:12, steve a écrit : Bonjour François-Marie, Que donne systemctl status systemd-sysusers.service ceci systemd-sysusers.service - Create System Users Loaded: loaded (/lib/systemd/system/systemd-sysusers.service; static; vendor Active: failed (Result: exit-code) since Thu 2020-04-30 12:42:19 CEST; 6min a Docs: man:sysusers.d(5) man:systemd-sysusers.service(8) Main PID: 586 (code=exited, status=1/FAILURE) avril 30 12:42:19 debian-0 systemd[1]: Starting Create System Users... avril 30 12:42:19 debian-0 systemd-sysusers[586]: Creating group systemd-coredum avril 30 12:42:19 debian-0 systemd-sysusers[586]: Creating user systemd-coredump avril 30 12:42:19 debian-0 systemd-sysusers[586]: Failed to write files: Invalid avril 30 12:42:19 debian-0 systemd[1]: systemd-sysusers.service: Main process ex avril 30 12:42:19 debian-0 systemd[1]: systemd-sysusers.service: Failed with res avril 30 12:42:19 debian-0 systemd[1]: Failed to start Create System Users. Et en root, que donne grpck -r 'utilisateur' is a member of the 'dialout' group in /etc/group but not in /etc/gshadow 'utilisateur' is a member of the 'plugdev' group in /etc/group but not in /etc/gshadow Steve Le jeudi 30 avril 2020, informatique a écrit : Bonjour, j'ai cette erreur lors du Boot de ma machine : Failed to start Create System Users sans savoir d'ou elle vient. Merci -- François-Marie Bonjout donc la réponse est un problème des utilisateurs avec le groupe gshadow ? Merci -- François-Marie
Re: acces au lecteur cdrom ? quel /dev/????
On 4/30/20 12:11 PM, Petrusko wrote: Bonjour à tous ! Je me demande comment accéder à mon lecteur de CDROM/DVD, à partir duquel j'aimerais créer une image .iso du disque qu'il contient. En voyant plusieurs tutos, je n'arrive pas à trouver dans quel /dev/x il se trouve ! (ou alors j'ai un problème hardware, possible aussi!) Y aurait-il une commande pour lister tous mes périphériques lecteurs connectés ? N'ayant pas réussi à trouver je me tourne vers vous. Oui, et plusieurs. Sous root évidemment dmesg lsusb paquet usbutils lspci paquet pciutils et surtout hwinfo du paquet hwinfo -- Basile STARYNKEVITCH == http://starynkevitch.net/Basile opinions are mine only - les opinions sont seulement miennes Bourg La Reine, France; (mobile phone: cf my web page / voir ma page web...)
Re: acces au lecteur cdrom ? quel /dev/????
Petrusko writes: > Je me demande comment accéder à mon lecteur de CDROM/DVD, à partir > duquel j'aimerais créer une image .iso du disque qu'il contient. > En voyant plusieurs tutos, je n'arrive pas à trouver dans quel > /dev/x il se trouve ! (ou alors j'ai un problème hardware, possible > aussi!) /dev/sr0 en général et des liens symboliques /dev/cdrom /dev/dvd -- Raphaël www.leclavierquibave.fr
Re: unexpected behavior of cp and mv
Hi, Alberto Sentieri wrote: > I tried setfattr as you suggested with "user" and without "user". Both > failed with "Operation not supported" and none of them changed the > timestamp. This only leaves the idea to mimick the strace of cp -p in an own C program to see whether utimensat() has the desired effect and whether following calls spoil it. Maybe it is necessary to really create a new file and to write some realistic amount of data to it in order to set up the conditions for the problem. The code of cp.c and copy.c in https://sources.debian.org/src/coreutils/8.30-3/src/ looks not overly self-contained. So it might be difficult to get a debuggable version of cp, if not Debian package development magic can produce it. Have a nice day :) Thomas
acces au lecteur cdrom ? quel /dev/????
Bonjour à tous ! Je me demande comment accéder à mon lecteur de CDROM/DVD, à partir duquel j'aimerais créer une image .iso du disque qu'il contient. En voyant plusieurs tutos, je n'arrive pas à trouver dans quel /dev/x il se trouve ! (ou alors j'ai un problème hardware, possible aussi!) Y aurait-il une commande pour lister tous mes périphériques lecteurs connectés ? N'ayant pas réussi à trouver je me tourne vers vous. Debian 10, lignes de commandes seulement. Merci d'avance pour votre précieuse aide :)
problème de console
bonjour, je suis sous Bullseyes depuis quelques temps j'ai un nouveau comportement des consoles de mon système Debian la console n°1 affiche les messages d'initialisation du système et est inaccessible à la connexion . habituellement je pouvais me connecter dessus après le démarrage du système. je n'ai pas trouvé d'erreur dans les logs. Est-ce un comportement normal ?
Re: Erreur non bloquante lors du Boot
Bonjour François-Marie, Que donne systemctl status systemd-sysusers.service Et en root, que donne grpck -r Steve Le jeudi 30 avril 2020, informatique a écrit : Bonjour, j'ai cette erreur lors du Boot de ma machine : Failed to start Create System Users sans savoir d'ou elle vient. Merci -- François-Marie
Re: fail2ban regex
Nisar JAGABAR a écrit : > > Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te > permets de le faire, regarde la sortie de 'fail2ban-client --help' ou > son man : > bash# fail2ban-client set banip > > Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un > bash# fail2ban-client status > > Pour les IP déjà bannis sur un JAIL particulier : > bash# fail2ban-client status Parce que le type est borné, que ça fait des jours que ça dure et que l'IP change régulièrement. Par ailleurs, fail2ban est fait pour cela et j'ai autre chose à faire que de surveiller /var/log/syslog. JKB
Re: fail2ban regex
Et pourquoi ne pas bannir manuellement cette IP ? fail2ban-client te
permets de le faire, regarde la sortie de 'fail2ban-client --help' ou
son man :
bash# fail2ban-client set banip
Pour le nom du JAIL, tu as une liste de ceux déjà configuré avec un
bash# fail2ban-client status
Pour les IP déjà bannis sur un JAIL particulier :
bash# fail2ban-client status
Le 29/04/2020 à 10:09, BERTRAND Joël a écrit :
Bonjour à tous,
Depuis plus de 48 heures, je subis une attaque sur l'un de mes serveurs
de mails en provenance de Russie. Les logs sont plein de ce genre de chose :
Apr 29 10:06:33 rayleigh pop3d-ssl: ip=[:::213.217.0.213], An
unexpected TLS packet was received.
Apr 29 10:06:33 rayleigh pop3d-ssl: Disconnected, ip=[:::213.217.0.213]
Et ça défile à une vitesse délirante. Je tente donc de rajouter une
règle fail2ban mais elle ne fait rien.
J'ai rajouté courier-tls.conf:
[INCLUDES]
before = common.conf
[Definition]
_daemon = (imapd-ssl|pop3d-ssl)?
failregex = ^.*ip=\[\], An unexpected TLS packet was received.$
ignoreregex =
datepattern = {^LN-BEG}
J'ai naturellement modifié le fichier de configuration de fail2ban et
cette règle est chargée :
2020-04-29 10:05:04,148 fail2ban.server [1114037]: INFO
Reload jail 'courier-tls'
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
encoding: UTF-8
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
maxRetry: 5
2020-04-29 10:05:04,148 fail2ban.filter [1114037]: INFO
findtime: 600
2020-04-29 10:05:04,148 fail2ban.actions[1114037]: INFO
banTime: 600
Mais elle ne fait rien. Si je la teste avec fail2ban-regex, elle semble
toutefois fonctionner. Où donc ai-je fait une boulette ?
Bien cordialement,
JKB
--
Nisar JAGABAR
,= ,-_-. =.
((_/)o o(\_))
`-'(. .)`-'
\_/
Re: Output from date command defaults to 12-hour in Buster.
On Mi, 29 apr 20, 19:18:14, Nicolas George wrote: > Andrei POPESCU (12020-04-29): > > Could you please kindly elaborate on this for the rest of the world > > where LANG is not some variant of en_XX ? > > I live in the rest of the world, and I do NOT want my numbers to have > commas in them instead of decimal points, nor do I want [0-9a-f] to > match "ça" and "fée". Do you? Actually I do. Now what? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Changing timestamps in video files
On Wed, Apr 29, 2020 at 4:17 PM David Wright wrote: > > On Wed 29 Apr 2020 at 13:16:17 (+0200), Anders Andersson wrote: > > On Wed, Apr 29, 2020 at 12:54 PM elvis wrote: > > > On 29/4/20 8:29 pm, Anders Andersson wrote: > > > > On Tue, Apr 28, 2020 at 5:57 PM Steve Keller > > > > wrote: > > > >> Is there any tool in Debian that is able to change the timestamp in > > > >> video files, e.g. .mov, .avi, .mp4, etc.? > > > >> > > > >> For image files I use jhead -ta but I haven't found > > > >> anything for video. > > > > $ ls -gGh faked_evidence.avi > > > > -rw-r--r-- 1 700M Apr 29 12:26 faked_evidence.avi > > > > $ touch -t 0512241337 faked_evidence.avi > > > > $ ls -gGh faked_evidence.avi > > > > -rw-r--r-- 1 700M Dec 24 2005 faked_evidence.avi > > > > > > Don't try that on faked_evidence.pdf > > > > > > Pdfs have an internal timestamp you need to change as well. > > > > > > > > > I think this is what he wants for movie files, but I am not sure they > > > have the time encoded into them... > > > > Sure. We can only guess what goes on in OPs mind. Could be basically > > anything, so I imagine this list of replies will grow until OP tells > > us what they want. > > Well, the OP wrote "in video files", which rules out touch. > It's pretty obvious that the OP is more interested in modifying > timestamps more like the one seen here, reading 210.718067. > > $ ffprobe 2037DFB67323C9DBA31FA6AE9C27A2670855D94A > Input #0, mpegts, from '2037DFB67323C9DBA31FA6AE9C27A2670855D94A': > Duration: 00:00:07.57, start: 210.718067, bitrate: 4413 kb/s > Program 1 > Metadata: > service_name: Service01 > service_provider: FFmpeg > Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), > yuv420p(progressive), 1920x1080, Closed Captions, 29.97 fps, 29.97 tbr, 90k > tbn, 59.94 tbc > Stream #0:1[0x101]: Audio: aac (LC) ([15][0][0][0] / 0x000F), 44100 Hz, > stereo, fltp, 102 kb/s > $ Or maybe he wants to change actual timestamps in video files, like this? https://i.stack.imgur.com/UcoNw.jpg It's far from obvious that he wants fragment timestamps since they would not apply to image files as he mentioned in the first post.
Re: Met welke pdf-lezer worden pdf's geopend?
Op 29-04-2020 om 23:52 schreef Dirk Ruijne: > Paul van der Vlis schreef op wo 29-04-2020 om 21:19 [+0200]: >> Op 29-04-2020 om 19:01 schreef Dirk Ruijne: >> >>> Bij mij wordt standaard documentviewer gebruik voor het openen van >>> bestanden. Die staat bovenin het rijtje van programma's in "openen >>> met" >> >> Maar hoe komt dat daar als jij dat niet hebt ingesteld? >> Dat was de vraag die ik probeerde te beantwoorden, want Sjoerd >> schreef >> "Dat heb ik trouwens nooit, op geen enkele manier, ingesteld." > Tsja. >> Dat heeft dus van alles met .desktop bestanden te maken, ze staan >> meestal in: /usr/share/applications/ >> > Dat zijn er nogal wat: >> root@ruijne:/usr/share/applications# ls -la *desktop | wc -l >> 270 > > Maar; > root@ruijne:/usr/share/applications# ls -la *pdf*desktop | wc -l > 1 > > En dat is: > root@ruijne:/usr/share/applications# ls -la *pdf*desktop > -rw-r--r-- 1 root root 3284 okt 13 2014 pdfmod.desktop > > Ik gebruik pdfmod nooit om pdf-bestanden te tonen. Ik snap het dus > niet. Je hebt ook programma's die PDF's kunnen openen die geen "pdf" in de naam hebben... > En o ja: > root@ruijne:/usr/share/applications# grep okular /etc/mailcap | wc -l > 64 > > En daar zitten ook in: > root@ruijne:/usr/share/applications# grep okular /etc/mailcap | grep > pdf | head -n 2 > application/pdf;okular > '%s';nametemplate=%s.pdf; test=test "$DISPLAY" != "" > application/x-pdf; okular > '%s';nametemplate=%s.pdf; test=test "$DISPLAY" != "" > > En toch documentviewer als standaardapplicatie voor het openen van pdf' > s. Ik zou dit eens doen in die map: grep -l "application/pdf" *.desktop Ik krijg dit lijstje: atril.desktop calibre-ebook-viewer.desktop calibre-gui.desktop gimp.desktop inkscape.desktop libreoffice-draw.desktop org.gnome.Evince.desktop xpdf.desktop Dat zijn dus applicaties die PDF's kunnen openen. Verwijder je default applicatie maar eens, je zult zien dat een ander dan opeens het default wordt. Maar welke, dat is vrij vaag. Dat kan een applicatie zijn die helemaal niet geschikt is, zoals Gimp. Groeten, Paul -- Paul van der Vlis Linux systeembeheer Groningen https://www.vandervlis.nl/
Erreur non bloquante lors du Boot
Bonjour, j'ai cette erreur lors du Boot de ma machine : Failed to start Create System Users sans savoir d'ou elle vient. Merci -- François-Marie
