Re: [arch-general] inotify and rsync as user
Le samedi 2 mai 2020 11:42:37 CEST siefke_lis...@web.de a écrit : > The result is same. When run ssh samsung it works, when I run sync_docs.sh > in shell it works. Why with systemd make it trouble? > > Thank you > Silvio I do some rsync replication based on cron jobs, without inotify nor systemd. keychain unscrewed the script for automation to succeed. At the top of the script : keychain --agents "ssh" &> /dev/null . $HOME/.keychain/$(hostname)-sh ssh-add &> /dev/null # ... rsync something ... This supposes that you have rightly setup SSH keys on both hosts, and that the private key on the source host is not encrypted. In case it might help. Regards.
Re: [arch-general] r8169: transmit queue 0 timed out - dying hardware?
Le dimanche 10 mai 2020 12:18:43 CEST Bjoern Franke via arch-general a écrit : > I've switched now to the r8168-lts module. My laptop uses the r8169 module (ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller). I have not seen any ethernet performance drop. I do upgrade regularly (excessively!) and have fired most kernel iterations. In case it might be useful. Regards.
Re: [arch-general] root login @ console
Le vendredi 13 novembre 2020 17:06:08 CET Jack Frost via arch-general a écrit : > So I foo-bared my /home partition, no big deal, done it before, and I >... Had a somehow similar problem yesterday. After removing all lines with 'pam_tally' in /etc/pam.d/login via ssh (fortunately worked), I could login as root at console. This module is reportedly deprecated. If there's a login.pacnew file, just replace the current login file with the pacnew one, unless you have custom settings in your login file. Regards.
[arch-general] Realtek RTL8111H NIC : does it just work?
Hello, I 'm planning to buy a PC with an MSI MPG X570 GAMING EDGE WIFI mother board, having a Realtek RTL8111H ethernet device, and install Arch of course. I 've seen many web pages about the need to install the r8168 package for it to work. Some pages hint that the r8169 driver should work too. Almost all of these sources are many years old. I wish some forum members could share their experience with this NIC on current kernel. Does it just work? Is the r8168 package mandatory? Can complex tweak be avoided? Thank you. -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: [arch-general] Realtek RTL8111H NIC : does it just work?
Thank you all. I can now choose this board definitely.
Re: [arch-general] gnupg version
Le mardi 1 décembre 2020 15:57:53 CET Alexander Epaneshnikov via arch-general a écrit : > hello. GnuPG 2.2.25 has been released it fixes bug which affects me. but > arch only has Version 2.2.24-1 in testing. my question is why it haven't > been updated? if the maintainer simply does not have time yet, then I > understand, but maybe there is another reason? GnuPG 2.2.24 is now available. If you badly need GnuPG 2.2.25, you may customize the PKGBUILD and build it.
[arch-general] Firewire : resume from suspend may fail
Hello,
Resume from suspend to RAM in KDE fails if no video cam has been used. The
camcorder is connected to a firewire card in a PCIE-1 expansion slot. If the
camcorder has been used and is connected, the machine resumes rightly to the
desktop.
When it does not resume, I get a black screen with a blinking cursor, no
mouse, no keyboard. Network was available once only to login through SSH. This
leaves no choice but a hard reboot. Fortunately, the disk partitions are
always clean. After the hard reboot, there's no single error message in /var/
log/{errors,kernel}.log, not even a single resume message from kernel.
I've tried, on their own, pcie_hp=nomsi, firewire_ohci.quirks={0x10,0x40} to no
avail.
Using :
kernel 5.3.x and 5.4.x.
FireWire (IEEE 1394): VIA Technologies, Inc. VT6306/7/8 [Fire II(M)] IEEE 1394
OHCI Controller (rev 46)
I'm about to remove the card once I've downloaded the recordings. I wish of
course no being obliged to do that.
Does anyone have some advice to fix that ?
Thanks.
Re: [arch-general] Firewire : resume from suspend may fail
Obviously, I did not precise that it happened after adding a firewire card on the PCIE-1 slot. I also did a system upgrade at the same time. After removing the firewire extension card, well, the problem persisted. I notice that this box would resume normally if it is suspended in a virtual terminal. And I recalled I had a similar problem on my laptop. I dropped this script in /usr/lib/systemd/system-sleep/ : #!/bin/bash if [ "$1" = "pre" ];then chvt 2 fi if [ "$1" = "post" ];then chvt 1 fi exit 0 The machine would then resume in KDE, after switching to a virtual terminal with no $DISPLAY on suspend, and back to VT 1 on resume. It does so with the firewire extension card back in place also. This seems to be related to KDE, and not the presence of a firewire card in the box. Sorry to have bothered you. Happy New Year !
Re: [arch-general] Automated check log and block postfix
Le mercredi 1 janvier 2020 10:27:02 CET siefke_lis...@web.de a écrit : > I have fail2ban installed but there is nothing happen with. Okay is connect > and disconnect. No error message. I not understand why is so but is ok. > > Is there a way to cat this mess and write it automated to iptables? Is > there other way to catch it with a tool? Would be great have someone > an idea here. > As far as I understand, you want to automate blocking IPV4 addresses to access the submission port too often. If you install xtables-addons, this may help : iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --set iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent --name XT_SUB --update --seconds 180 --hitcount 5 --rttl -j DROP Adapt -i to your system, and tune --seconds plus --hitcount to your requirements. iptables -m recent --help for more information. It's quite complex. I've got rather good results with this. But you may also block yourself or other legitimate access. This may not fit large professional setups, rather your own postfix instance for personal use. Regards.
Re: [arch-general] Automated check log and block postfix
Le mercredi 1 janvier 2020 11:48:20 CET SET via arch-general a écrit : > iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent > --name XT_SUB --set > iptables -A INPUT -p tcp -d 587 -i eth0 -m state --state NEW -m recent > --name XT_SUB --update --seconds 180 --hitcount 5 --rttl -j DROP > ERRATUM --dport 587 should be used, instead of -d 587 '-d' refers to a host address/mask.
Re: [arch-general] Adding a "posix" metapackage
Le samedi 4 janvier 2020 16:50:24 CET Neven Sajko via arch-general a écrit : > http://www.etalabs.net/sh_tricks.html Thank you very much. Your 'echo' insight and fundamentals highlight differences between professionals and amateurs like me !
