Re: [CentOS] Postfix restrictions
On Tue, Jun 9, 2020 at 12:10 AM Peter wrote: > On 9/06/20 2:56 pm, Jon LaBadie wrote: > > Don't use a backup MX, they are a relic of the 90s when mail servers > were often times not always online. a sending mail server will > generally retry the message for up to five days if your MTA is down Or have your backup MX be the same as your primary and well behaved senders will try backup MX right away leading to little delay due to graylisting. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix restrictions
On 9/06/20 2:56 pm, Jon LaBadie wrote: I hit another limitation. My backup MX handler is a 3rd party who will not use greylisting. Thus all the 1st timers I rejected just delivered to my alternate MX address and were not blocked at all. Don't use a backup MX, they are a relic of the 90s when mail servers were often times not always online. a sending mail server will generally retry the message for up to five days if your MTA is down so backup MXes are really not necessary. As you have discovered, if you do decide to use a backup MX it really needs to have exactly the same anti-spam protections as the primary MX, but most backup MXes don't and spammers know this. In fact many spammers will ignore the primary MX all together and push out SPAM directly to the backup MX. Peter ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix restrictions
yeah, then don't use a backup MX server at all. I dropped using one when I realized most spam prevention would just end up at the backup which didn't have the same rules as long as your server has a decent uptime and is never down more than a few hours and that very rarely, then you really don't need a backup server at all. On Mon, Jun 8, 2020 at 7:57 PM Jon LaBadie wrote: > On Sun, Jun 07, 2020 at 05:53:28AM -0700, John Pierce wrote: > > On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs wrote: > > > > > > > > My aim is simply to eliminate as much spam as possible (that is, before > > > adding > > > SpamAssassin) while keeping false positives to a minimum. > > > > > > > The one thing that stopped the most spam on my last mailserver was > > greylisting. Any mta that connects to you to send you mail, you check > > against a white list, and if they are not on it, you reject the > connection > > with a 'try again later' code and add them to a grey list that will let > > them in after 10 minutes or so. The vast majority of spambots don't > queue > > up retries, they just move on to the next target. > > > > The downside of greylisting is delayed delivery of mail from non white > > listed servers, dependent on their retry cycle. > > I hit another limitation. My backup MX handler is a 3rd party who > will not use greylisting. Thus all the 1st timers I rejected just > delivered to my alternate MX address and were not blocked at all. > > Jon > -- > Jon H. LaBadie j...@labadie.us > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > -- -john r pierce recycling used bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Postfix restrictions
On Sun, Jun 07, 2020 at 05:53:28AM -0700, John Pierce wrote: > On Sun, Jun 7, 2020, 2:47 AM Nicolas Kovacs wrote: > > > > > My aim is simply to eliminate as much spam as possible (that is, before > > adding > > SpamAssassin) while keeping false positives to a minimum. > > > > The one thing that stopped the most spam on my last mailserver was > greylisting. Any mta that connects to you to send you mail, you check > against a white list, and if they are not on it, you reject the connection > with a 'try again later' code and add them to a grey list that will let > them in after 10 minutes or so. The vast majority of spambots don't queue > up retries, they just move on to the next target. > > The downside of greylisting is delayed delivery of mail from non white > listed servers, dependent on their retry cycle. I hit another limitation. My backup MX handler is a 3rd party who will not use greylisting. Thus all the 1st timers I rejected just delivered to my alternate MX address and were not blocked at all. Jon -- Jon H. LaBadie j...@labadie.us ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Trying to get bride network on CentOS 7 working with virt-manager
On 6/8/20 3:46 PM, Jerry Geis wrote: I have these interfaces listed. virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 virbr1: flags=4099 mtu 1500 inet 192.168.100.1 netmask 255.255.255.0 broadcast 192.168.100.255 Those interfaces are for NAT networks, not bridged networks. The easiest way to set up bridged networking on CentOS 7 is: virsh iface-bridge eth0 br0 --no-stp This command will create a new bridge interface, br0. The existing interface, eth0, will be added to the bridge, and its current IP configuration will be migrated to the new interface. (This should work for C8, but I haven't deployed KVM on C8 yet) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Trying to get bride network on CentOS 7 working with virt-manager
I have these interfaces listed. eth0: flags=4163 mtu 1500 inet 192.168.1.8 netmask 255.255.252.0 broadcast 192.168.3.255 inet6 fe80::e2d5:5eff:fe63:abe5 prefixlen 64 scopeid 0x20 ether e0:d5:5e:63:ab:e5 txqueuelen 1000 (Ethernet) RX packets 42411243 bytes 4701898681 (4.3 GiB) RX errors 0 dropped 156 overruns 0 frame 0 TX packets 78372982 bytes 34946337897 (32.5 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 16 memory 0x92f0-92f2 virbr0: flags=4099 mtu 1500 inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255 ether 52:54:00:fc:34:af txqueuelen 1000 (Ethernet) RX packets 132792 bytes 337411780 (321.7 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 138593 bytes 742263806 (707.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr1: flags=4099 mtu 1500 inet 192.168.100.1 netmask 255.255.255.0 broadcast 192.168.100.255 ether 52:54:00:9c:39:02 txqueuelen 1000 (Ethernet) RX packets 206217 bytes 132308800 (126.1 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 105448 bytes 197008661 (187.8 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 virbr0-nic: flags=4099 mtu 1500 ether 52:54:00:fc:34:af txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 When I bring up virt-manager, got settings for my VM, and for "Network Source" I select "Specify Shared Device Name" and I have tried the virbr0 and clicked apply and boot the machine. I get networking but not bridged networking - not a 192.168.1.X address. Is there something I missed ? Thanks, Jerry ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/dnf diff
On Mon, Jun 08, 2020 at 04:00:31PM +0100, Paddy Doyle wrote: > Just to mention that 'etckeeper' from EPEL is a great way of tracking Ah, I see you mentioned you were using that already in the original post. Sorry for the noise. Paddy ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/dnf diff
On Fri, Jun 05, 2020 at 12:34:07PM -0700, Kenneth Porter wrote: > I'm trying to figure out > what edits I made to my config files. > > My most recent case was trying to figure out what I'd done to my BIND files > (/etc/named.*, /etc/logrotate.d/named, /var/named/*). I ended up just > tarring them up and erasing and re-installing the bind package, then > untarring my old config into a tmp directory and diffing the files > individually, reapplying appropriate changes. Just to mention that 'etckeeper' from EPEL is a great way of tracking changes in /etc. It interfaces nicely with yum, such that installing a package means that it will commit changes to the /etc repo. And there's a daily crontab that commits changes. You can manually commit changes as well. Then you can 'git log -p' to see what changes were made to the file over time. It won't track /var/named/* though. Paddy -- Paddy Doyle Research IT / Trinity Centre for High Performance Computing, Lloyd Building, Trinity College Dublin, Dublin 2, Ireland. Phone: +353-1-896-3725 https://www.tchpc.tcd.ie/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/dnf diff
On 6/5/20 4:31 PM, Kenneth Porter wrote: > --On Friday, June 05, 2020 1:39 PM -0700 John Pierce > wrote: > >> don't most packages create a .rpmnew file if you've modified the previous >> package file ? > > That file is created AFTER you've made edits, and reflects only the > state of the file in the latest package. So it's not clear what changed > from the original package that needs to be migrated into one's current > settings. > > As a rule I try to copy the original files to xxx.original so I can > compare that to both the .rpmnew file and my working file. But I or > another admin might forget to save the original. So I end up going the > cpio route to extract the original files to a temp tree to do the 3-way > comparison between the original, my modifications, and the latest > package's modifications. Do your mods in a local git repo .. if you mod the exploded tarball, do it via a spec patch. If you mod config files .. create a separate branch from the rpm and put the mods in (if you can't do it via a spec patch). Then when new files come in .. just reapply (or refactor if necessary) the original diff. That is exactly what we do for packages we modify .. look at Firefox as an example: https://git.centos.org/rpms/firefox/commits/c7 signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] C8 install problems
Hi all, I am trying to install C8 from a DVD I made onto a 1Tb disc partitioned into 2 ext4 partitions. The first partition contains C7 which I installed via a DVD. Trying to install C8 yields an error indicating the file /dev/root is missing. I've checked the SHA256 sum for the ISO for CentOS 8.1 1911 and it checks out fine. I've burned a couple of different DVDs and get the same error about /dev/root missing from both. I burned both DVDs using the PC app PowerISO. Is that potentially a problem ? Looking at the log file of the C8 install I see before the message about /dev/root, that the file /etc/iscsi/initiatorname.iscsi is missing --and /sbin/modprobe -bv sg failed w/ exit code 1 I am doing the install with the target 1Tb disc attached, via a USB cable from a SATA docking station, to a ASUS PC running Windows 7. I boot up via the DVD just fine on the PC, but I've not been able to get past the errors from iSCSI and /dev/root. I do see a message at the very beginning of the install that the hardware family 12h is "not supported upstream". I'm not sure if that message is important, or a red herring. Is it possible that the Orico SATA docking station (model 6619) has been dropped in C8 ? Any tips or suggestions would be greatly appreciated. Thanks, --Ed ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
