Re: [gentoo-user] Re: Internet slow at times. Can't figure out why. ISP??
J. Roeleveld wrote: > On Tuesday, April 7, 2020 5:54:25 AM CEST Ian Zimmerman wrote: >> On 2020-04-06 22:14, Dale wrote: >>> I have DSL and it isn't to fast to begin with. At >>> times tho, I'm only getting about 20 or 30% of what I should. >> Are you often on the phone at those times? May it be poor filtering? >> >> At my last residence - also "in the sticks", LOL - we had to give up on >> DSL completely, because 6 times out of 10 when we got a phone call the >> internet dropped. Seriously. We're not proud to support the Comcast >> monopoly, but what a difference. > This is likely caused by NOT having a filter for every device. > > Longer version: > > DSL requires a splitter/filter between the wall-socket (where the phone > normally plugs in) and the DSL modem. It also has a 2nd connection for the > phone. > > This filter needs to be installed between ALL phone-wall-sockets and any > device plugged in. > > (Alternatively, you place the filter at the main entry-point and connect the > router from that filter and run the "phone" port to the rest of the house.) > > The phone part has been cut off for a long time. The only wire left is the one to the modem itself. I forgot but I ran a brand new wire a good while back when I moved the jack. This is a long term issue tho. I might add, the DSL box up the road is full. The only way a new person can get DSL is if someone else cuts theirs off. It's been full since about three months after they installed the DSL box. I actually have some extra filters tho. Since I don't have any use for them anymore. lol It was a good thought tho. I had a filter go bad once and it did wreak havoc on the DSL. Poor internet, DSL signal lost at times. If the phone rang or anyone picked up a phone, dead DSL for sure. Dale :-) :-)
[gentoo-user] CHOST for Celeron J4105 processor
Hi, I have an Odroid H2 with a Celeron J4105 processor which appears to be a Gemini Lake, Goldmont Plus architecture Any idea what CHOST this should be? BillK
Re: [gentoo-user] Internet slow at times. Can't figure out why. ISP??
On Tuesday, April 7, 2020 5:14:14 AM CEST Dale wrote: > Hey, > > As some may recall I bought a new router and modem. I was sort of > hoping one or both of those would solve a issue I've noticed for a good > long while. At times, my internet gets really slow, slower than it > should be at least. I have DSL and it isn't to fast to begin with. At > times tho, I'm only getting about 20 or 30% of what I should. This is > what the modem shows for speed: > > Downstream Rate 1536 Kbps > Upstream Rate 384 Kbps > > Don't laugh OK. I live in the sticks and for many years, I was lucky to > get 26K down on dial-up. I hoping for faster one day but this is better > than dial-up, mostly. ;-) If it works. And I remember when I was stuck with a 14k4 modem in the olden days. > Here's some info. This slow down seems to always happen in the > evenings, somewhere between 6 and 9PM. Isn't this when people sit down to eat and possible start watching netflix or other streaming services? Or the kids playing games before going to bed? > Generally, the rest of the time > it is pretty close to its max speed. Because it works most of the time, > I'm thinking this is not hardware or cable related. I'd think it more > consistently slow if it was. That said, it does the same with any > modem, any router or any sets of cables. I even bought some bulk cable > and ends then made my own cables and tested them with a ohm meter to be > sure they were really good. No improvement. I also disabled the > wireless on my cell phone to be sure it wasn't doing something funny. It > is set to download only when I tell it but there is one google thing > that ignores that. I agree. It doesn't sound like a hardware problem. If it were, the issue would be far more consistent and not limited to a, near fixed, time period. > The only things I see is in the logs. Here is some of the log from the > modem, currently the Netgear 7550. > > > 2020/04/06 21:54:15 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= > MAC= SRC=185.175.93.23 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 > TTL=241 ID=29175 PROTO=TCP SPT=56054 DPT=5937 WINDOW=1024 RES=0x00 SYN > URGP=0 OPT (020405AC) > > 2020/04/06 21:54:13 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= > MAC= SRC=176.113.115.54 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 > TTL=240 ID=34879 PROTO=TCP SPT=50930 DPT=1683 WINDOW=1024 RES=0x00 SYN > URGP=0 OPT (020405AC) 2020/04/06 21:54:03 CDT WRN | kernel | > logInboundBlocked:IN=ppp0 OUT= MAC= SRC=176.113.115.52 > DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 TTL=240 ID=21875 PROTO=TCP > SPT=50932 DPT=31240 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) > 2020/04/06 21:53:43 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= > MAC= SRC=185.153.198.249 DST=74.188.249.233 LEN=44 TOS=0x08 PREC=0x20 > TTL=234 ID=8388 PROTO=TCP SPT=58950 DPT=33995 WINDOW=1024 RES=0x00 SYN > URGP=0 OPT (020405AC) 2020/04/06 21:53:39 CDT WRN | kernel | > ICMP:logOutboundBlocked:IN= OUT=ppp0 SRC=74.188.249.233 > DST=152.32.191.35 LEN=34 TOS=0x00 PREC=0x00 TTL=64 ID=6687 PROTO=ICMP > TYPE=0 CODE=0 ID=16298 SEQ=0 2020/04/06 21:53:32 CDT WRN | kernel | > logInboundBlocked:IN=ppp0 OUT= MAC= SRC=51.178.78.153 DST=74.188.249.233 > LEN=44 TOS=0x08 PREC=0x20 TTL=238 ID=54321 PROTO=TCP SPT=58684 DPT=8000 > WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:53:24 CDT > WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=185.153.198.240 > DST=74.188.249.233 LEN=44 TOS=0x08 PREC=0x20 TTL=234 ID=43550 PROTO=TCP > SPT=50631 DPT=47025 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) > 2020/04/06 21:53:19 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= > MAC= SRC=216.58.193.142 DST=74.188.249.233 LEN=40 TOS=0x00 PREC=0x80 > TTL=121 ID=0 DF PROTO=TCP SPT=443 DPT=50020 WINDOW=0 RES=0x00 RST URGP=0 > 2020/04/06 21:53:01 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= > MAC= SRC=146.88.240.4 DST=74.188.249.233 LEN=78 TOS=0x00 PREC=0x00 > TTL=245 ID=54321 PROTO=UDP SPT=43443 DPT=137 LEN=58 2020/04/06 21:52:58 > CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= > SRC=176.113.115.247 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 TTL=240 > ID=64147 PROTO=TCP SPT=50902 DPT=31405 WINDOW=1024 RES=0x00 SYN URGP=0 > OPT (020405AC) 2020/04/06 21:52:50 CDT WRN | kernel | > logInboundBlocked:IN=ppp0 OUT= MAC= SRC=170.106.36.63 DST=74.188.249.233 > LEN=44 TOS=0x08 PREC=0x00 TTL=243 ID=54321 PROTO=TCP SPT=59903 DPT=5938 > WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC) > > > I googled but didn't really find anything, good or bad, about those > entries. This is from the router, the TP-Link I bought a few months ago. Looks like standard port-scanners. The logs indicate they are blocked. So should be ok. Make sure you have all the security settings enabled on the router (and only disable the ones that are causing issues) > Index Time Type Level Log Content > 199 Apr 6 21:57:17 DHCP INFO DHCPS:Send ACK to 192.168.0.100 > 198 Apr 6 21:57:17 DHCP INFO DHCPS:Recv REQUEST
Re: [gentoo-user] Re: Internet slow at times. Can't figure out why. ISP??
On Tuesday, April 7, 2020 5:54:25 AM CEST Ian Zimmerman wrote: > On 2020-04-06 22:14, Dale wrote: > > I have DSL and it isn't to fast to begin with. At > > times tho, I'm only getting about 20 or 30% of what I should. > > Are you often on the phone at those times? May it be poor filtering? > > At my last residence - also "in the sticks", LOL - we had to give up on > DSL completely, because 6 times out of 10 when we got a phone call the > internet dropped. Seriously. We're not proud to support the Comcast > monopoly, but what a difference. This is likely caused by NOT having a filter for every device. Longer version: DSL requires a splitter/filter between the wall-socket (where the phone normally plugs in) and the DSL modem. It also has a 2nd connection for the phone. This filter needs to be installed between ALL phone-wall-sockets and any device plugged in. (Alternatively, you place the filter at the main entry-point and connect the router from that filter and run the "phone" port to the rest of the house.)
Re: [gentoo-user] Alternate Incoming Mail Server
On Monday, April 6, 2020 11:17:58 PM CEST Ashley Dixon wrote: > On Mon, Apr 06, 2020 at 11:34:02AM -0600, Grant Taylor wrote: > > On 4/6/20 6:35 AM, Ashley Dixon wrote: > > > Hello, > > > > Hi, > > Hello, > > [O.T.] Unfortunately, Grant, I cannot reply to your direct e-mail. My best > guess is that you have a protection method in place in the event that the > reverse D.N.S.\ does not match the forward ? As I'm on a domestic I.P., > this is out of my control (i.e., `nslookup mail.suugaku.co.uk` returns my > I.P., but `nslookup ` returns some obscure hostname provided by my > I.S.P.). I am afraid most (if not all) ISPs will reject emails if the reverse DNS does not match. Using a dynamic range is another "spam" indicator and will also get your emails blocked by (nearly) all ISPs. I would suggest putting your outbound SMTP server on a cheap VM hosted somewhere else. Or you get an outbound SMTP-service that allows you to decide on domain name and email addresses. -- Joost
[gentoo-user] Is Hardened profile and SELinux support active?
Hi everyone, I am very new to Gentoo and I am currently migrating from Arch. Gentoo attracts me with a freedom of system configuration and with multiple supported architectures. I was attracted by Hardened profile described at [1][2][3] But reading [1] I also got confused because it looks like it is no longer maintained. So the question is it just outdated wiki page? Is anyone using Hardened profile? Is it maintained? In Archlinux SELinux is not supported officially so this is why I am looking around. Thanks/ [1] https://wiki.gentoo.org/wiki/Project:Hardened[1] [2] https://wiki.gentoo.org/wiki/Hardened/FAQ[2] [3] https://wiki.gentoo.org/wiki/Hardened_Gentoo[3] -- Ihor Antonov https://useplaintext.email [1] https://wiki.gentoo.org/wiki/Project:Hardened [2] https://wiki.gentoo.org/wiki/Hardened/FAQ [3] https://wiki.gentoo.org/wiki/Hardened_Gentoo
Re: [gentoo-user] Alternate Incoming Mail Server
On Monday, April 6, 2020 7:35:40 PM CEST Michael Orlitzky wrote: > On 4/6/20 1:32 PM, J. Roeleveld wrote: > > The messages were missing due to the MX being unavailable for a short > > period. Retries were not attempted as I would have received them. > > > > The spam filter is configured with certain mailing lists whitelisted. > > Here is proof that the Gentoo list server retries after ~8 minutes: > > Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT > from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable; > from=, > to=, proto=ESMTP, helo= > > Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass > (mailfrom) identity=mailfrom; client-ip=208.92.234.80; > helo=lists.gentoo.org; envelope-from > =gentoo-announce+bounces-2524-michael=orlitzky@lists.gentoo.org; > receiver= > > I'm not saying you're lying about what happened, but that the conclusion > you're drawing from it is premature. The Gentoo list server (and every > other real MTA) retries deliveries. If you lost a message, I'd bet > that's not the reason why. It was a few years ago, so no longer have the logs. The outage was around 30 minutes (which I still consider a short time) and even after a few weeks, the emails didn't appear. I no longer have this issue as I have 2 MXs in different datacenters. I am also not willing to disable both MXs to see if this still occurs. -- Joost
[gentoo-user] Re: Internet slow at times. Can't figure out why. ISP??
On 2020-04-06 22:14, Dale wrote: > I have DSL and it isn't to fast to begin with. At > times tho, I'm only getting about 20 or 30% of what I should. Are you often on the phone at those times? May it be poor filtering? At my last residence - also "in the sticks", LOL - we had to give up on DSL completely, because 6 times out of 10 when we got a phone call the internet dropped. Seriously. We're not proud to support the Comcast monopoly, but what a difference. -- Ian
[gentoo-user] Internet slow at times. Can't figure out why. ISP??
Hey, As some may recall I bought a new router and modem. I was sort of hoping one or both of those would solve a issue I've noticed for a good long while. At times, my internet gets really slow, slower than it should be at least. I have DSL and it isn't to fast to begin with. At times tho, I'm only getting about 20 or 30% of what I should. This is what the modem shows for speed: Downstream Rate 1536 Kbps Upstream Rate 384 Kbps Don't laugh OK. I live in the sticks and for many years, I was lucky to get 26K down on dial-up. I hoping for faster one day but this is better than dial-up, mostly. ;-) Here's some info. This slow down seems to always happen in the evenings, somewhere between 6 and 9PM. Generally, the rest of the time it is pretty close to its max speed. Because it works most of the time, I'm thinking this is not hardware or cable related. I'd think it more consistently slow if it was. That said, it does the same with any modem, any router or any sets of cables. I even bought some bulk cable and ends then made my own cables and tested them with a ohm meter to be sure they were really good. No improvement. I also disabled the wireless on my cell phone to be sure it wasn't doing something funny. It is set to download only when I tell it but there is one google thing that ignores that. The only things I see is in the logs. Here is some of the log from the modem, currently the Netgear 7550. 2020/04/06 21:54:15 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=185.175.93.23 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 TTL=241 ID=29175 PROTO=TCP SPT=56054 DPT=5937 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:54:13 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=176.113.115.54 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 TTL=240 ID=34879 PROTO=TCP SPT=50930 DPT=1683 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:54:03 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=176.113.115.52 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 TTL=240 ID=21875 PROTO=TCP SPT=50932 DPT=31240 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:53:43 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=185.153.198.249 DST=74.188.249.233 LEN=44 TOS=0x08 PREC=0x20 TTL=234 ID=8388 PROTO=TCP SPT=58950 DPT=33995 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:53:39 CDT WRN | kernel | ICMP:logOutboundBlocked:IN= OUT=ppp0 SRC=74.188.249.233 DST=152.32.191.35 LEN=34 TOS=0x00 PREC=0x00 TTL=64 ID=6687 PROTO=ICMP TYPE=0 CODE=0 ID=16298 SEQ=0 2020/04/06 21:53:32 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=51.178.78.153 DST=74.188.249.233 LEN=44 TOS=0x08 PREC=0x20 TTL=238 ID=54321 PROTO=TCP SPT=58684 DPT=8000 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:53:24 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=185.153.198.240 DST=74.188.249.233 LEN=44 TOS=0x08 PREC=0x20 TTL=234 ID=43550 PROTO=TCP SPT=50631 DPT=47025 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:53:19 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=216.58.193.142 DST=74.188.249.233 LEN=40 TOS=0x00 PREC=0x80 TTL=121 ID=0 DF PROTO=TCP SPT=443 DPT=50020 WINDOW=0 RES=0x00 RST URGP=0 2020/04/06 21:53:01 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=146.88.240.4 DST=74.188.249.233 LEN=78 TOS=0x00 PREC=0x00 TTL=245 ID=54321 PROTO=UDP SPT=43443 DPT=137 LEN=58 2020/04/06 21:52:58 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=176.113.115.247 DST=74.188.249.233 LEN=44 TOS=0x00 PREC=0x00 TTL=240 ID=64147 PROTO=TCP SPT=50902 DPT=31405 WINDOW=1024 RES=0x00 SYN URGP=0 OPT (020405AC) 2020/04/06 21:52:50 CDT WRN | kernel | logInboundBlocked:IN=ppp0 OUT= MAC= SRC=170.106.36.63 DST=74.188.249.233 LEN=44 TOS=0x08 PREC=0x00 TTL=243 ID=54321 PROTO=TCP SPT=59903 DPT=5938 WINDOW=65535 RES=0x00 SYN URGP=0 OPT (020405AC) I googled but didn't really find anything, good or bad, about those entries. This is from the router, the TP-Link I bought a few months ago. Index Time Type Level Log Content 199 Apr 6 21:57:17 DHCP INFO DHCPS:Send ACK to 192.168.0.100 198 Apr 6 21:57:17 DHCP INFO DHCPS:Recv REQUEST from 00:01:53:80:DC:35 197 Apr 6 21:21:57 DHCP INFO DHCPS:Send ACK to 192.168.0.101 196 Apr 6 21:21:57 DHCP INFO DHCPS:Recv REQUEST from A8:87:B3:B4:F9:5E 195 Apr 6 20:57:17 DHCP INFO DHCPS:Send ACK to 192.168.0.100 194 Apr 6 20:57:17 DHCP INFO DHCPS:Recv REQUEST from 00:01:53:80:DC:35 193 Apr 6 20:24:21 DHCP INFO DHCPS:Send ACK to 192.168.0.101 192 Apr 6 20:24:21 DHCP INFO DHCPS:Recv REQUEST from A8:87:B3:B4:F9:5E 191 Apr 6 19:57:17 DHCP INFO DHCPS:Send ACK to 192.168.0.100 190 Apr 6 19:57:17 DHCP INFO DHCPS:Recv REQUEST from 00:01:53:80:DC:35 I'm only copying a small portion of it because it is very repetitive. It's pretty much the same thing over and over again. I'm not thinking those are errors tho. The router sure does send recv DHCP stuff often tho. Does anyone see anything that
Re: [gentoo-user] Idea for Videoconferencing (Video part)
On 4/3/20 5:16 AM, Petric Frank wrote: Hello, this is not exactly a gentoo issue. But due i am using gentoo i am asking here. Problem: Usually the camera is outside of the screen. The user normally looks at the screen. As result the communication partner(s) see him not looking at the camera. Idea: Use two cameras positioned left and right or top and bottom of the screen. Combine the two video streams and generate a third stream having a virtual camera positioned at the middle of the screen. Result: Better communication. The partners always looking in their eyes. At the same time the screen contents can be viewed. Is this description clear enough ? Sounds that feasible ? Anyone taking the task ? Or is there a better place to post such an idea ? kind regards Petric "stereoscopic" is but one technology where dual camera feeds are combined. Just mount one on top, center of the monitor. Routine solution. old background: https://en.wikipedia.org/wiki/Stereo_camera lucidcam ~$17.00 https://www.e-consystems.com/3D-USB-stereo-camera.asp https://www.stereolabs.com/zed/ https://www.stereolabs.com/ Other hacks through expensive solutions exist. I'd think a single lens camera mounted on top, center of the monitor, 4K resolution, would solve your issues, better than (2) integrated lenses. ymmv. hth, James
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Monday, 6 April 2020 22:15:20 BST Neil Bothwick wrote: > On Mon, 6 Apr 2020 22:02:04 +0100, antlists wrote: > > > This isn't strictly true, the ESP must be vfat, but you can still > > > have an ext? /boot. > > > > This isn't true at all - you've got the cart before the horse. The > > original (U)EFI spec comes from Sun, I believe, with no vfat in sight. > > > > A standards-compliant factory-fresh Mac boots using UEFI with no vfat > > in sight. > > That's true, but firmware on commodity PC motherboards can only be relied > upon to handle vfat. So while my use of "must" is a bit strong, it should > be vfat if you want to be sure it will boot on a PC. Perhaps older UEFI specifications allowed Mac-baked filesystems, or perhaps Apple were/are doing their own thing. The current UEFI specification *requires* a FAT 12/16/32 filesystem type on an ESP partition to boot an OS image/bootloader from - see section '13.3 File System Format': https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf I can't recall the ESP partition format last time I installed and dual-booted Linux on a MacBookPro, c.2014, but I'd wager it was VFAT. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, Apr 6, 2020 at 4:02 PM Grant Taylor wrote: > > On 4/6/20 1:03 PM, Rich Freeman wrote: > > More often than not, yes. The main exception I've seen are sites > > that email you verification codes, such as some sorts of "two-factor" > > implementations (whether these are really two-factor I'll set aside > > for now). Many of these services will retry, but some just give up > > after one attempt. > > I believe that's a perfect example of services that should send email > through a local MTA that manages a queue and retries mail delivery. > There is no need for this type of queuing logic and complexity to be in > the application. Especially if the application is otherwise stateless > and runs for the duration of a single HTTP request. Sure, but: 1. We're talking about people who think email is a great solution to 2FA. and 2. Why use a standard MTA when you can build one yourself? I believe this is a corollary to Zawinski's Law. -- Rich
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 3:17 PM, Ashley Dixon wrote: Hello, Hi, [O.T.] Unfortunately, Grant, I cannot reply to your direct e-mail. My best guess is that you have a protection method in place in the event that the reverse D.N.S.\ does not match the forward ? You're close. I do require reverse DNS. I will log a warning if forward and reverse don't match, but the email should still flow. Lack of reverse DNS is problematic though. As I'm on a domestic I.P., this is out of my control (i.e., `nslookup mail.suugaku.co.uk` returns my I.P., but `nslookup ` returns some obscure hostname provided by my I.S.P.). Oops! Been there. Done that. I've added your mail server's name & IPv4 & IPv6 addresses to my /etc/hosts file. Please try again. I'll also send you an email from an alternate address. Sadly, it doesn't look like you can use the hack that I've used in the past. If forward and reverse DNS do match , you can configure your outgoing email server to simply use that name when talking to the outside world. Unfortunately, it doesn't look like you can do that because the forward DNS doesn't return an A / record for the name name that the PTR returns. This sounds quite enticing; I'll have a look, thanks :) :-) I didn't mean to infer that my back-up server would be different to my primary server, as my primary is rather minimal. And yes, good point, I suppose if anything, I should have tougher anti-spam measures on my backup MX :) For simplicity and consistency sake, I'd encourage you to have the same spam / virus / hygiene filtering on all mail servers that you control. This is what I was intending to do. I hadn't even considered dynamically playing with the D.N.S., given that addresses are commonly cached for a short period to avoid hammering name-servers (?) You have influence on how long things are cached for by adjusting the TTL value in your DNS. I say "influence" vs "control" because not all recursive DNS servers honor the TTL value that you specify. Some servers set a lower and / or upper bound on the TTL that they will honor. Oh my goodness, I feel silly now :) I was considering just using courier to catch the incoming mail, and then rsync it over to my primary when it comes back on-line, I supposed that you could have a full functional mail server, including delivering to mailboxes and then synchronizing the mailboxes between the servers. But that would be more work, and I'm guessing that's contrary to the simple alternate server that I think you are after. but using an S.M.T.P.-forwarder certainly seems more elegant. ;-) Cheers for your help and detailed explanations Grant. Not only will your suggestions make my humble mail server operate better, but it's also great fun to set up :) You're quite welcome. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On Mon, Apr 06, 2020 at 11:34:02AM -0600, Grant Taylor wrote: > On 4/6/20 6:35 AM, Ashley Dixon wrote: > > Hello, > > Hi, Hello, [O.T.] Unfortunately, Grant, I cannot reply to your direct e-mail. My best guess is that you have a protection method in place in the event that the reverse D.N.S.\ does not match the forward ? As I'm on a domestic I.P., this is out of my control (i.e., `nslookup mail.suugaku.co.uk` returns my I.P., but `nslookup ` returns some obscure hostname provided by my I.S.P.). > I encourage you to take a look at Junk Email Filter's Project Tar [1]. > > Aside: JEF-PT encourages people to add a high order MX to point to JEF-PT > in the hopes that undesirable email to your domain will hit their MX, which > will always defer the email and never accept it. Their hope is to attract > as many bad actors to their system as they can, where they analyze the > behavior of the sending system; does it follow RFCs, does it try to be a > spam cannon, etc. They look at the behavior, NEVER content, and build an > RBL. The provide this RBL for others to use if they desire. — I have been > using, and recommending, JEF-PT for more than a decade. > > JEF-PT could function as the backup MX in a manner of speaking. They will > never actually accept your email. But they will look like another email > server to senders. As such, well behaved senders will queue email for later > delivery attempts. This sounds quite enticing; I'll have a look, thanks :) > > I also want the solution to be as minimal as possible. I see the problem > > as three parts: > > This type of thinking is how you end up with different spam / virus / > hygiene capabilities between the primary and secondary email systems. Hence > why many undesirables try secondary email system(s) first. ;-) > > If you're going to run a filter on your primary mail server, you should also > run the filter on your secondary mail server(s). I didn't mean to infer that my back-up server would be different to my primary server, as my primary is rather minimal. And yes, good point, I suppose if anything, I should have tougher anti-spam measures on my backup MX :) > > (a) Convincing the D.N.S.\ and my router to redirect mail to the > > alternate server, should the default one not be reachable; > > DNS is actually trivial. That's where multiple MX records come in to play. > — This is actually more on the sending system honoring what DNS publishes > than it is on the DNS server. This is what I was intending to do. I hadn't even considered dynamically playing with the D.N.S., given that addresses are commonly cached for a short period to avoid hammering name-servers (?) > > (b) Creating the alternate mail server to be as lightweight as possible. > > I'm not even sure if I need an S.M.T.P.\ server (postfix). Would > > courier-imap do the trick on its own (with courier-authlib and mysql) ? > > You will need an SMTP server, or other tricks ~> hacks. Remember that > you're receiving email from SMTP servers, so you need something that speaks > SMTP to them. > > Courier IMAP & authlib are not SMTP servers. I sincerely doubt that they > could be made to do what you are wanting. Oh my goodness, I feel silly now :) I was considering just using courier to catch the incoming mail, and then rsync it over to my primary when it comes back on-line, but using an S.M.T.P.-forwarder certainly seems more elegant. > Or, you can use SMTP, which you're already using, and does exactly what > you're asking to do. Cheers for your help and detailed explanations Grant. Not only will your suggestions make my humble mail server operate better, but it's also great fun to set up :) -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Mon, 6 Apr 2020 22:02:04 +0100, antlists wrote: > > This isn't strictly true, the ESP must be vfat, but you can still > > have an ext? /boot. > > This isn't true at all - you've got the cart before the horse. The > original (U)EFI spec comes from Sun, I believe, with no vfat in sight. > > A standards-compliant factory-fresh Mac boots using UEFI with no vfat > in sight. That's true, but firmware on commodity PC motherboards can only be relied upon to handle vfat. So while my use of "must" is a bit strong, it should be vfat if you want to be sure it will boot on a PC. -- Neil Bothwick Top Oxymorons Number 2: Exact estimate pgp9F40M_ebwH.pgp Description: OpenPGP digital signature
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On 05/04/2020 13:52, Neil Bothwick wrote: This isn't strictly true, the ESP must be vfat, but you can still have an ext? /boot. This isn't true at all - you've got the cart before the horse. The original (U)EFI spec comes from Sun, I believe, with no vfat in sight. A standards-compliant factory-fresh Mac boots using UEFI with no vfat in sight. A standards-compliant UEFI firmware MUST BE CAPABLE of booting from (a certain version of) vfat. So if you use a vfat partition the spec says it must work. It doesn't demand you use vfat, so Macs use HFS+ or whatever it is, and there is no reason why eg System7 couldn't write their own firmware to use ext2 or whatever. Cheers, Wol
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 3:59 PM, Grant Taylor wrote: >· It's not five seconds a year. > · It's more likely an hour or two a year, possibly aggregated. >· You can't control the retry time frame on the sending side. >· You can control the retry / forward time on secondary MX(s). >· Messages can be canceled while sitting in sending systems queues. >· It's much more difficult for someone to interfere with messages > sitting on your systems. > · Especially without your knowledge. >· It's /still/ considered best practice to have /multiple/ inbound MX > servers. > · Be it primary / secondary > · Anycasted instance > · Other tricks >· Do you want to tell the CEO that he can't have his email for 36 > hours because you patched the mail server and the sender's system won't > retry for 35.5 hours? > > My professional and personal opinion is that if you're serious about > email, then you should have multiple inbound MX servers. > The same RFC suggests how long the sending system should wait to retry: Experience suggests that failures are typically transient (the target system or its connection has crashed), favoring a policy of two connection attempts in the first hour the message is in the queue, and then backing off to one every two or three hours. The SMTP client can shorten the queuing delay in cooperation with the SMTP server. For example, if mail is received from a particular address, it is likely that mail queued for that host can now be sent. Application of this principle may, in many cases, eliminate the requirement for an explicit "send queues now" function such as ETRN, RFC 1985 [36]. If someone decides to configure his mail server to retry only after a week, then sure, there's not much you can do about it. But it's not really fair for you to cherry-pick this one specific way that a sender can ignore the RFC, and claim that because a sender can ignore the RFC in this way, that it's better to adopt a different architecture that relies on the sender following the RFC in *another* very specific way (trying the backup MX sooner than they would retry the primary MX). Why aren't we pretending the sender will ignore that part of the RFC instead? The real-life manifestations of these problems are non-existent. Anyone who reads this thread and still decides to maintain a second MX to mitigate these purely-hypothetical issues does so only at the risk of his own free time and money. Caveat emptor =)
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/6/20 1:16 PM, Michael Orlitzky wrote: Greylisting suffers from one problem that unplugging the server doesn't: greylisting usually works on a triple like (IP address, sender, recipient), and can therefore continue to reject people who do retry, but retry from a different IP address. This occasionally affects things like Github notifications and requires manual intervention. I used to be a strong advocate of greylisting. I had some of the problems that have been described. Then I switched to Nolisting, a close varient of greylisting that I haven't seen any of the same (or any) problems with. If a sending email server follows the RFCs and tries multiple MXs, then email gets through in seconds instead of having to re-try and wait for a greylist timeout. There's also no issue with (re)trying from different IPs. (I would still recommend greylisting, personally, but it's a harder sell than that of foregoing a secondary MX.) Greylisting, or better, nolisting is a very good thing. See my other email for why I disagree about foregoing additional MXs. -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/6/20 1:03 PM, Rich Freeman wrote: More often than not, yes. The main exception I've seen are sites that email you verification codes, such as some sorts of "two-factor" implementations (whether these are really two-factor I'll set aside for now). Many of these services will retry, but some just give up after one attempt. I believe that's a perfect example of services that should send email through a local MTA that manages a queue and retries mail delivery. There is no need for this type of queuing logic and complexity to be in the application. Especially if the application is otherwise stateless and runs for the duration of a single HTTP request. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 11:55 AM, Michael Orlitzky wrote: Ok, you're right. ;-) My suggestion to create multiple records was in response to the claim that there are MTAs that will try a backup MX, but won't retry the primary MX, which is false to begin with. Trying to argue against an untrue premise only muddied the water. I will not exclude the possibility of email sending programs that will use backup MX(s) and not use the primary MX. But these are not general purpose MTAs. Back to the point: all real MTAs retry messages. You can find bulk mailers and spam zombies and one or two java "forgot password" webforms from 1995 that won't retry; but by and large, everyone does. By and large, yes all well behaved MTAs do re-try. The web form is a classic example of what a local queuing MTA is good for. If anyone has evidence to the contrary, it should be easy to find and present. If, on the other hand no such MTAs exist, then it's quite pointless to run a second MX for the five seconds a year that it's useful. I disagree. · I've seen connectivity issues break connection between a sending host and a primary MX. · Receiving side · Sending side · Breakage in the Internet (outside of the direct providers on the ends) · combination of the above · It's not five seconds a year. · It's more likely an hour or two a year, possibly aggregated. · You can't control the retry time frame on the sending side. · You can control the retry / forward time on secondary MX(s). · Messages can be canceled while sitting in sending systems queues. · It's much more difficult for someone to interfere with messages sitting on your systems. · Especially without your knowledge. · It's /still/ considered best practice to have /multiple/ inbound MX servers. · Be it primary / secondary · Anycasted instance · Other tricks · Do you want to tell the CEO that he can't have his email for 36 hours because you patched the mail server and the sender's system won't retry for 35.5 hours? My professional and personal opinion is that if you're serious about email, then you should have multiple inbound MX servers. -- Grant. . . . unix || die -- Grant. . . . unix || die
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On 4/6/20 3:03 PM, Rich Freeman wrote: > > More often than not, yes. The main exception I've seen are sites that > email you verification codes, such as some sorts of "two-factor" > implementations (whether these are really two-factor I'll set aside > for now). Many of these services will retry, but some just give up > after one attempt. Greylisting suffers from one problem that unplugging the server doesn't: greylisting usually works on a triple like (IP address, sender, recipient), and can therefore continue to reject people who do retry, but retry from a different IP address. This occasionally affects things like Github notifications and requires manual intervention. (I would still recommend greylisting, personally, but it's a harder sell than that of foregoing a secondary MX.)
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, Apr 6, 2020 at 12:18 PM Ian Zimmerman wrote: > > On 2020-04-06 14:24, Ashley Dixon wrote: > > > Cheers for the help ! To be honest, I don't think I'd want to receive > > e-mail from someone who cannot resist pressing a button :) > > In fact, "MTAs" that don't retry turn out to be spam robots on close > inspection, more often than not. That is the basis for the spam > fighting tactic called "greylisting". So you will not even be original > in ignoring them. > More often than not, yes. The main exception I've seen are sites that email you verification codes, such as some sorts of "two-factor" implementations (whether these are really two-factor I'll set aside for now). Many of these services will retry, but some just give up after one attempt. Solutions like postgrey make it easy to whitelist particular MTAs or destination addresses to avoid this problem. I won't say that greylisting has solved all my spam problems but it definitely cuts down on it. Also, by delaying never-before-seen MTAs it also makes it more likely that RBLs and such will be updated before the email makes it past greylisting, which will cut down on "zero day" spam. -- Rich
Re: [gentoo-user] Alternate Incoming Mail Server
"Michael Orlitzky" , 06.04.2020, 19:35: > On 4/6/20 1:32 PM, J. Roeleveld wrote: >> >> The messages were missing due to the MX being unavailable for a short >> period. Retries were not attempted as I would have received them. >> >> The spam filter is configured with certain mailing lists whitelisted. >> > Here is proof that the Gentoo list server retries after ~8 minutes: > Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT > from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable; > from=, > to=, proto=ESMTP, helo= > Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass > (mailfrom) identity=mailfrom; client-ip=208.92.234.80; > helo=lists.gentoo.org; envelope-from > =gentoo-announce+bounces-2524-michael=orlitzky@lists.gentoo.org; > receiver= > I'm not saying you're lying about what happened, but that the conclusion > you're drawing from it is premature. The Gentoo list server (and every > other real MTA) retries deliveries. If you lost a message, I'd bet > that's not the reason why. And here's an example for J. Roeleveld's observed missed original messages: A few days ago I sent a message to this list. As usual, I received a bunch of DMARC reports from mailservers rejecting the messages. > From: "Seznam.cz" > This is a spf/dkim authentication-failure report for an email message received > from IP 208.92.234.80 on Sun, 05 Apr 2020 22:14:23 +0200. > > The message below did not meet the sending domain's dmarc policy. The headers of that rejected message start with > Received: from lists.gentoo.org (unknown [208.92.234.80]) > by email-smtpd3.ng.seznam.cz (Seznam SMTPD 1.3.108) with ESMTP; > Sun, 05 Apr 2020 22:14:22 +0200 (CEST) This means that folks @seznam.cz (among others) will not get to see this message unless somebody replies to it from a domain that uses a less restrictive combination of SPF, DKIM and DMARC rules. So one possible cause for receiving replies to messages you didn't receive is the right mixture of configuration of sending domain and transmitting mail server. s.
[gentoo-user] Re: How to configure keyboard layout for X11 libinput?
On 2020-04-06, Mike Gilbert wrote: >> I also had to remove the "XkbRules" option. Now the keyboard mapping >> is back to "normal". 'Twould be nice if things like that were >> documented somewhere, but I'm not sure where it would be... > > Take a look at the libinput(4) man page, which is installed by > x11-drivers/xf86-input-libinput. Nothing there except mouse/trackpad stuff. I don't see anything about keyboard layout in general or XkbRules in particular. -- Grant
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 1:44 PM, Grant Taylor wrote: > On 4/6/20 11:14 AM, Michael Orlitzky wrote: >> Why don't you say which MTA it is that both (a) combines MX records with >> different priorities, and (b) doesn't retry messages to the primary MX? > > You seem to have conflated the meaning of my message. > > I only stated that I've seen multiple MTAs to (a) combine MX records. > > I never said that those MTAs also didn't (b) retry message delivery. > Ok, you're right. My suggestion to create multiple records was in response to the claim that there are MTAs that will try a backup MX, but won't retry the primary MX, which is false to begin with. Trying to argue against an untrue premise only muddied the water. Back to the point: all real MTAs retry messages. You can find bulk mailers and spam zombies and one or two java "forgot password" webforms from 1995 that won't retry; but by and large, everyone does. If anyone has evidence to the contrary, it should be easy to find and present. If, on the other hand no such MTAs exist, then it's quite pointless to run a second MX for the five seconds a year that it's useful.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 11:14 AM, Michael Orlitzky wrote: Why don't you say which MTA it is that both (a) combines MX records with different priorities, and (b) doesn't retry messages to the primary MX? You seem to have conflated the meaning of my message. I only stated that I've seen multiple MTAs to (a) combine MX records. I never said that those MTAs also didn't (b) retry message delivery. I have seen the following MTAs do (a) in the past: · Microsoft Exchange · IIS SMTP service · Novell GroupWise · Lotus Domino · Sendmail · Postfix Those are the ones that come to mind. I'm sure there are others that I ran into less frequently. My understanding from researching this years ago is that it used to be considered a configuration error to have multiple MX records with names that resolve to the same IP. As such, MTAs would combine them / deduplicated them to avoid wasted resource consumption. There is no point trying to connect to the same IP, even by a different name, an additional time after the previous time failed during the /current/ delivery / queue cycle. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 1:32 PM, J. Roeleveld wrote: > > The messages were missing due to the MX being unavailable for a short period. > Retries were not attempted as I would have received them. > > The spam filter is configured with certain mailing lists whitelisted. > Here is proof that the Gentoo list server retries after ~8 minutes: Mar 12 15:15:42 mx1 postfix/postscreen[27586]: NOQUEUE: reject: RCPT from [208.92.234.80]:47590: 450 4.3.2 Service currently unavailable; from=, to=, proto=ESMTP, helo= Mar 12 15:23:07 mx1 policyd-spf[20627]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=208.92.234.80; helo=lists.gentoo.org; envelope-from =gentoo-announce+bounces-2524-michael=orlitzky@lists.gentoo.org; receiver= I'm not saying you're lying about what happened, but that the conclusion you're drawing from it is premature. The Gentoo list server (and every other real MTA) retries deliveries. If you lost a message, I'd bet that's not the reason why.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 6:35 AM, Ashley Dixon wrote: Hello, Hi, After many hours of confusing mixtures of pain and pleasure, I have a secure and well-behaved e-mail server which encompasses all the features I originally desired. Full STOP! I hoist my drink to you and tell the bar keep that your next round is on me. Very nicely done!!! In all seriousness, running your own email server is definitely not easy. DNS, web, and database servers are easier. This is especially true, by an order of magnitude, if you are going to be sending email and do all of the necessary things to get other mail receivers to be happy with email outbound from your server. ~hat~tip~ However, in the event that I need to reboot the server (perhaps a kernel update was added to Portage), I would like to have a miniature mail server which catches incoming mail if, and only if, my primary server is down. Okay I have Gentoo installation on an old Raspberry Pi (model B+), and was curious if such a set-up was possible ? Can you get a Raspberry Pi to function as a backup server? Yes. Do you want to do such, maybe, maybe not. I've seen heavier inbound email load on my backup mail server(s) than I have on my main mail server. This is primarily because some, undesirables, send email to the backup email server in the hopes that there is less spam / virus / hygiene filtering there. The thought process is that people won't pay to license / install / maintain such software on the ""backup email server. I encourage you to take a look at Junk Email Filter's Project Tar [1]. Aside: JEF-PT encourages people to add a high order MX to point to JEF-PT in the hopes that undesirable email to your domain will hit their MX, which will always defer the email and never accept it. Their hope is to attract as many bad actors to their system as they can, where they analyze the behavior of the sending system; does it follow RFCs, does it try to be a spam cannon, etc. They look at the behavior, NEVER content, and build an RBL. The provide this RBL for others to use if they desire. — I have been using, and recommending, JEF-PT for more than a decade. JEF-PT could function as the backup MX in a manner of speaking. They will never actually accept your email. But they will look like another email server to senders. As such, well behaved senders will queue email for later delivery attempts. I also want the solution to be as minimal as possible. I see the problem as three parts: This type of thinking is how you end up with different spam / virus / hygiene capabilities between the primary and secondary email systems. Hence why many undesirables try secondary email system(s) first. ;-) In for a penny, in for a pound. If you're going to run a filter on your primary mail server, you should also run the filter on your secondary mail server(s). (a) Convincing the D.N.S.\ and my router to redirect mail to the alternate server, should the default one not be reachable; DNS is actually trivial. That's where multiple MX records come in to play. — This is actually more on the sending system honoring what DNS publishes than it is on the DNS server. Aside: Were you talking about changing what DNS publishes dynamically based on the state of your email server? If so, there is a lot more involved with this, and considerably more gotchas / toe stubbers to deal with. There are some networking tricks that you can do in some situations to swing the IP of your email server to another system. This assumes that they are on the same LAN. · VRRP is probably the simplest one. · Manually moving also works, but is less simple. · Scripting is automated manual. · Routing is more complex. · Involves multiple subnets · May involve dynamic routing protocols · Manual / scripting · NAT modification is, problematic (b) Creating the alternate mail server to be as lightweight as possible. I'm not even sure if I need an S.M.T.P.\ server (postfix). Would courier-imap do the trick on its own (with courier-authlib and mysql) ? You will need an SMTP server, or other tricks ~> hacks. Remember that you're receiving email from SMTP servers, so you need something that speaks SMTP to them. Courier IMAP & authlib are not SMTP servers. I sincerely doubt that they could be made to do what you are wanting. (c) Moving mail from the alternate server to the main server once the latter has regained conciousness. SMTP has this down pat in spades. This is actually what SMTP does, move email from system to system to system. You really are simply talking about conditinally adding another system to that list. Hint: SMTP is the industry standard solution for what you're wanting to do, /including/ getting the email from the alternate server to the main server. I realise this is a slightly different problem, and is not even necessarily _required_ for operation, although it's certainly a
Re: [gentoo-user] Alternate Incoming Mail Server
On 6 April 2020 19:25:13 CEST, Michael Orlitzky wrote: >On 4/6/20 1:19 PM, J. Roeleveld wrote: >> >> I have missed emails coming from mailing lists, this one for example, >due to no retries. >> The proof for that is that I got replies to emails I never received. >> > >That doesn't prove that the server never retried, it proves that you >didn't receive one particular message that was sent from the list. The >most common reason for that is that your spam filter blocked the >original message, but not the reply. Retries only happen for 4xx errors >(like "connection timed out," when the server is down) and not for 5xx >errors (like "this is spam, go away"). The messages were missing due to the MX being unavailable for a short period. Retries were not attempted as I would have received them. The spam filter is configured with certain mailing lists whitelisted. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 1:24 PM, Robert Bridge wrote: > > But that is just an anecdote. > It's very easy to collect evidence of this from the mail logs if you are correct.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 1:19 PM, J. Roeleveld wrote: > > I have missed emails coming from mailing lists, this one for example, due to > no retries. > The proof for that is that I got replies to emails I never received. > That doesn't prove that the server never retried, it proves that you didn't receive one particular message that was sent from the list. The most common reason for that is that your spam filter blocked the original message, but not the reply. Retries only happen for 4xx errors (like "connection timed out," when the server is down) and not for 5xx errors (like "this is spam, go away").
Re: [gentoo-user] Alternate Incoming Mail Server
On 6 Apr 2020, at 18:20, J. Roeleveld wrote: > > On 6 April 2020 19:14:35 CEST, Michael Orlitzky wrote: >>> On 4/6/20 1:02 PM, Grant Taylor wrote: >>> On 4/6/20 10:43 AM, Michael Orlitzky wrote: Well, I can't refute an anecdote without more information, but if you're worried about this you can create the same MX record twice so >> that the "backup" is the primary. >>> >>> That's not going to work as well as you had hoped. >>> >>> I've run into many MTAs that check things and realize that the hosts >> in >>> multiple MX records resolve to the same IP and treat them as one. >>> >> >> Why don't you say which MTA it is that both (a) combines MX records >> with >> different priorities, and (b) doesn't retry messages to the primary MX? > > I have missed emails coming from mailing lists, this one for example, due to > no retries. > The proof for that is that I got replies to emails I never received. But that is just an anecdote.
Re: [gentoo-user] Alternate Incoming Mail Server
On 6 April 2020 19:14:35 CEST, Michael Orlitzky wrote: >On 4/6/20 1:02 PM, Grant Taylor wrote: >> On 4/6/20 10:43 AM, Michael Orlitzky wrote: >>> Well, I can't refute an anecdote without more information, but if >>> you're worried about this you can create the same MX record twice so > >>> that the "backup" is the primary. >> >> That's not going to work as well as you had hoped. >> >> I've run into many MTAs that check things and realize that the hosts >in >> multiple MX records resolve to the same IP and treat them as one. >> > >Why don't you say which MTA it is that both (a) combines MX records >with >different priorities, and (b) doesn't retry messages to the primary MX? I have missed emails coming from mailing lists, this one for example, due to no retries. The proof for that is that I got replies to emails I never received. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 1:02 PM, Grant Taylor wrote: > On 4/6/20 10:43 AM, Michael Orlitzky wrote: >> Well, I can't refute an anecdote without more information, but if >> you're worried about this you can create the same MX record twice so >> that the "backup" is the primary. > > That's not going to work as well as you had hoped. > > I've run into many MTAs that check things and realize that the hosts in > multiple MX records resolve to the same IP and treat them as one. > Why don't you say which MTA it is that both (a) combines MX records with different priorities, and (b) doesn't retry messages to the primary MX?
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 10:43 AM, Michael Orlitzky wrote: Well, I can't refute an anecdote without more information, but if you're worried about this you can create the same MX record twice so that the "backup" is the primary. That's not going to work as well as you had hoped. I've run into many MTAs that check things and realize that the hosts in multiple MX records resolve to the same IP and treat them as one. You may get this to work. But I would never let clients to rely on this. -- Grant. . . . unix || die
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 10:19 AM, J. Roeleveld wrote: I find that, with a backup MX, I don't seem to loose emails. Having multiple email servers of your own, primary, secondary, tertiary, etc, makes it much more likely that the email will move from the sending systems control to your control. I think it's fairly obvious that having the inbound email somewhere you control it is self evident. I've run into poorly configured sending servers that will try (re)sending once a day / week. So, you would be waiting on them for that day / week to re-send, presuming they do re-send. Conversely, if you have your own secondary mail server, the inbound message will likely land at the secondary mail server seconds ~> minutes after being unable to send to the primary mail server. Thus when your primary mail server comes back online minutes later, your secondary can send it on to your primary. Thus a net delay of minutes vs hours / days / week(s). I have, however, found evidence of mailservers belonging to big ISPs not retrying emails if there is no response from the singular MX. I've not noticed this, but I've not been looking for it, and I've had secondary email servers for decades. Note: You don't have to have and manage your own secondary mail server. You can outsource the task to someone you trust. The primary thing is that there are multiple servers willing to accept responsibility for your email. Be they your servers and / or someone else's servers acting as your agent. General call to everybody: If you're an individual and you want a backup (inbound relay) email server, send me a direct email and we can chat. I want to do what I can to help encourage people to run their own servers. I'm happy to help. -- Grant. . . . unix || die
Re: [gentoo-user] Re: How to configure keyboard layout for X11 libinput?
On Mon, Apr 6, 2020 at 11:12 AM Grant Edwards wrote: > > On 2020-04-06, Grant Edwards wrote: > > On 2020-04-06, Michael wrote: > > > >> Did you try '/etc/X11/xorg.conf.d/10-evdev.conf' ? > > > > My keyboard config is in /etc/X11/xorg.conf.d/30-keyboard.conf > > > > The control/capslock key mapping still works, but the keyboard layout > > is borked. If I remove that file, the control/capslock mapping stops > > working (as expected), and the kayboard layout is OK. > > > > Next, I tried just removing 'Option "XkbLayout'", and that made no > > difference. Here is what I started with: > > > > Section "InputClass" > > Identifier "keyboard-all" > > Driver "libinput" > > Option "XkbLayout" "us" > > Option "XkbRules" "xorg" > > Option "XkbOptions" "ctrl:nocaps,compose:ralt" > > MatchIsKeyboard "on" > > EndSection > > I also had to remove the "XkbRules" option. Now the keyboard mapping > is back to "normal". 'Twould be nice if things like that were > documented somewhere, but I'm not sure where it would be... Take a look at the libinput(4) man page, which is installed by x11-drivers/xf86-input-libinput.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 12:19 PM, J. Roeleveld wrote: > > I find that, with a backup MX, I don't seem to loose emails. > I have, however, found evidence of mailservers belonging to big ISPs not > retrying emails if there is no response from the singular MX. > Well, I can't refute an anecdote without more information, but if you're worried about this you can create the same MX record twice so that the "backup" is the primary.
Re: [gentoo-user] Re: Alternate Incoming Mail Server
On Mon, Apr 06, 2020 at 09:18:10AM -0700, Ian Zimmerman wrote: > In fact, "MTAs" that don't retry turn out to be spam robots on close > inspection, more often than not. That is the basis for the spam > fighting tactic called "greylisting". So you will not even be original > in ignoring them. Hmm, that's an interesting point, thanks :) [Off-Topic] For the moment I have zero anti-spam measures on my mail server (probably not the greatest thing to admit on a public list). I'll add them if required, but so far---a couple of months of on-and-off service---I haven't received any messages which I didn't expect. I suppose bots will start to harvest my addresses from my website and various public keyservers soon, but for now spam hasn't been a concern at all. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Alternate Incoming Mail Server
On 6 April 2020 18:02:22 CEST, Michael Orlitzky wrote: >On 4/6/20 11:51 AM, Robert Bridge wrote: >> >> It is still commonly considered good practice to have a secondary MX >server. > >[citation needed] > > >> Why trust another party to correctly handle your email when your main >system is offline? > >You're still trusting the sender to do the right thing with a backup >MX. >Only now you're trusting them to follow the part of the spec that talks >about backup MX records, rather than the part that talks about retries. I find that, with a backup MX, I don't seem to loose emails. I have, however, found evidence of mailservers belonging to big ISPs not retrying emails if there is no response from the singular MX. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] Re: Alternate Incoming Mail Server
On 2020-04-06 14:24, Ashley Dixon wrote: > Cheers for the help ! To be honest, I don't think I'd want to receive > e-mail from someone who cannot resist pressing a button :) In fact, "MTAs" that don't retry turn out to be spam robots on close inspection, more often than not. That is the basis for the spam fighting tactic called "greylisting". So you will not even be original in ignoring them. -- Ian
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 11:51 AM, Robert Bridge wrote: > > It is still commonly considered good practice to have a secondary MX server. [citation needed] > Why trust another party to correctly handle your email when your main system > is offline? You're still trusting the sender to do the right thing with a backup MX. Only now you're trusting them to follow the part of the spec that talks about backup MX records, rather than the part that talks about retries.
Re: [gentoo-user] Alternate Incoming Mail Server
On 6 Apr 2020, at 16:35, Ashley Dixon wrote: > > On Mon, Apr 06, 2020 at 05:24:03PM +0200, J. Roeleveld wrote: >> You'd need to install a SMTP server on the backup system and configure it to >> relay emails to your primary mailserver. >> >> In the DNS you can configure priorities in the MX entries. > > Hi, cheers for your response, however as Michael pointed out, such a server > would be unnecessary. I wasn't aware of the S.M.T.P.\ standard which mandates > M.T.A.s retry for four or five days, and given that my server won't be down > for > longer than a few minutes, I think I'm going to stick with a single MX. It is still commonly considered good practice to have a secondary MX server. I have encountered some DNS control panels which actually refuse to allow you to only configure a single MX record! Why trust another party to correctly handle your email when your main system is offline?
Re: [gentoo-user] Alternate Incoming Mail Server
On Mon, Apr 06, 2020 at 05:24:03PM +0200, J. Roeleveld wrote: > You'd need to install a SMTP server on the backup system and configure it to > relay emails to your primary mailserver. > > In the DNS you can configure priorities in the MX entries. Hi, cheers for your response, however as Michael pointed out, such a server would be unnecessary. I wasn't aware of the S.M.T.P.\ standard which mandates M.T.A.s retry for four or five days, and given that my server won't be down for longer than a few minutes, I think I'm going to stick with a single MX. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Alternate Incoming Mail Server
On 6 April 2020 14:35:04 CEST, Ashley Dixon wrote: >Hello, > >After many hours of confusing mixtures of pain and pleasure, I have a >secure and >well-behaved e-mail server which encompasses all the features I >originally >desired. However, in the event that I need to reboot the server >(perhaps a >kernel update was added to Portage), I would like to have a miniature >mail >server which catches incoming mail if, and only if, my primary server >is down. > >I have Gentoo installation on an old Raspberry Pi (model B+), and was >curious if >such a set-up was possible ? I also want the solution to be as minimal >as >possible. I see the problem as three parts: > >(a) Convincing the D.N.S.\ and my router to redirect mail to the >alternate > server, should the default one not be reachable; > >(b) Creating the alternate mail server to be as lightweight as >possible. I'm >not even sure if I need an S.M.T.P.\ server (postfix). Would >courier-imap do > the trick on its own (with courier-authlib and mysql) ? > >(c) Moving mail from the alternate server to the main server once the >latter >has regained conciousness. I realise this is a slightly different >problem, and >is not even necessarily _required_ for operation, although it's >certainly a > nice-to-have. > >What do you think; is this at all possible ? Has anyone here done >anything like >this before ? > >Thanks in advance. You'd need to install a SMTP server on the backup system and configure it to relay emails to your primary mailserver. In the DNS you can configure priorities in the MX entries. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[gentoo-user] Re: How to configure keyboard layout for X11 libinput?
On 2020-04-06, Grant Edwards wrote: > On 2020-04-06, Michael wrote: > >> Did you try '/etc/X11/xorg.conf.d/10-evdev.conf' ? > > My keyboard config is in /etc/X11/xorg.conf.d/30-keyboard.conf > > The control/capslock key mapping still works, but the keyboard layout > is borked. If I remove that file, the control/capslock mapping stops > working (as expected), and the kayboard layout is OK. > > Next, I tried just removing 'Option "XkbLayout'", and that made no > difference. Here is what I started with: > > Section "InputClass" > Identifier "keyboard-all" > Driver "libinput" > Option "XkbLayout" "us" > Option "XkbRules" "xorg" > Option "XkbOptions" "ctrl:nocaps,compose:ralt" > MatchIsKeyboard "on" > EndSection I also had to remove the "XkbRules" option. Now the keyboard mapping is back to "normal". 'Twould be nice if things like that were documented somewhere, but I'm not sure where it would be... -- Grant
[gentoo-user] Re: How to configure keyboard layout for X11 libinput?
On 2020-04-06, Michael wrote: > On Monday, 6 April 2020 15:37:34 BST Grant Edwards wrote: >> I switched from evdev to libinput as recommeded by recent news, and >> now my keyboard is hosed: a bunch of keys are unrecognized or send the >> wrong thing. (Arrow keys don't work, right-CTRL causes screen to >> flash, pgup/pgdown don't work, etc.). Unfortunately, all of the >> keyboard layout documentation I find talks about evdev, but doesn't >> mention libinput: >> >> https://wiki.gentoo.org/wiki/Keyboard_layout_switching >> >> Where/how to I set keyboard layout for libinput? >> >> -- >> Grant > > Did you try '/etc/X11/xorg.conf.d/10-evdev.conf' ? My keyboard config is in /etc/X11/xorg.conf.d/30-keyboard.conf The control/capslock key mapping still works, but the keyboard layout is borked. If I remove that file, the control/capslock mapping stops working (as expected), and the kayboard layout is OK. Next, I tried just removing 'Option "XkbLayout'", and that made no difference. Here is what I started with: Section "InputClass" Identifier "keyboard-all" Driver "libinput" Option "XkbLayout" "us" Option "XkbRules" "xorg" Option "XkbOptions" "ctrl:nocaps,compose:ralt" MatchIsKeyboard "on" EndSection Here's what I have no (no difference in behavior): Section "InputClass" Identifier "keyboard-all" Driver "libinput" Option "XkbRules" "xorg" Option "XkbOptions" "ctrl:nocaps,compose:ralt" MatchIsKeyboard "on" EndSection
Re: [gentoo-user] How to configure keyboard layout for X11 libinput?
On Monday, 6 April 2020 15:37:34 BST Grant Edwards wrote: > I switched from evdev to libinput as recommeded by recent news, and > now my keyboard is hosed: a bunch of keys are unrecognized or send the > wrong thing. (Arrow keys don't work, right-CTRL causes screen to > flash, pgup/pgdown don't work, etc.). Unfortunately, all of the > keyboard layout documentation I find talks about evdev, but doesn't > mention libinput: > > https://wiki.gentoo.org/wiki/Keyboard_layout_switching > > Where/how to I set keyboard layout for libinput? > > -- > Grant Did you try '/etc/X11/xorg.conf.d/10-evdev.conf' ? It still works here. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Preparing a blank NVMe as a boot drive...
On Monday, 6 April 2020 15:38:00 BST Neil Bothwick wrote: > On Mon, 6 Apr 2020 16:26:27 +0200, tu...@posteo.de wrote: > > Do I really need an image on an USBstick to boot into UEFI mode > > just to setup a system to boot into UEFI mode? > > Yes. The bootloader needs access to the EFI variables to set itself up > and those are only present when booting with EFI. > > You may also want to consider using something other than GRUB for EFI > booting. Either systemd-boot (this package is for non-systemd users, it > is already included with systemd) or reFind. For completeness I mention here that with UEFI firmware on the MoBo you may not even need a boot manager at all. That's how I boot a number of UEFI systems here: https://wiki.gentoo.org/wiki/EFI_stub_kernel signature.asc Description: This is a digitally signed message part.
[gentoo-user] How to configure keyboard layout for X11 libinput?
I switched from evdev to libinput as recommeded by recent news, and now my keyboard is hosed: a bunch of keys are unrecognized or send the wrong thing. (Arrow keys don't work, right-CTRL causes screen to flash, pgup/pgdown don't work, etc.). Unfortunately, all of the keyboard layout documentation I find talks about evdev, but doesn't mention libinput: https://wiki.gentoo.org/wiki/Keyboard_layout_switching Where/how to I set keyboard layout for libinput? -- Grant
Re: [gentoo-user] Preparing a blank NVMe as a boot drive...
On Mon, 6 Apr 2020 16:26:27 +0200, tu...@posteo.de wrote: > Do I really need an image on an USBstick to boot into UEFI mode > just to setup a system to boot into UEFI mode? Yes. The bootloader needs access to the EFI variables to set itself up and those are only present when booting with EFI. You may also want to consider using something other than GRUB for EFI booting. Either systemd-boot (this package is for non-systemd users, it is already included with systemd) or reFind. -- Neil Bothwick - How many surrealists does it take to change a light bulb? - Two: one to hold the giraffe, the other to fill the bathtub with lots of brightly colored machine tools. pgpPn5h37WOVv.pgp Description: OpenPGP digital signature
[gentoo-user] Re: Copying root to SSD in one go...a good idea...or?
On 2020-04-06, Jack wrote: > On 4/6/20 9:35 AM, Grant Edwards wrote: >> On 2020-04-06, William Kenworthy wrote: >> >>> Use rsync with the bwlimit option to slow down the overall data rate - >>> monitor the temp with smart and slow it up if needed (I actually don't >>> think you will have a problem.) >> Does bwlimit work with local copies? The man page says specifically >> it's for limiting bandwidthon sockets. > > Can't you use the network syntax for one end of the rsync transfer to > bring the socket controls into play? Sure, if you want to route all the data through the network stack. You'll have to configure rsync to listen on localhost, and it seems like a waste, but it should work to limit bandwidth.
Re: [gentoo-user] Preparing a blank NVMe as a boot drive...
On 04/06 03:35, Andrea Conti wrote: > > Then there was something mentioned about namespaces, which should > > be allocated smaller than the physical drive > > Is this really needed - just to boot from this SSD? > > NVMe namespaces are an abstraction layer that allows a controller to present > its connected storage as a number of independent volumes. > Think LVM LVs, or the way a hardware RAID card presents volumes as multiple > SCSI LUNs. > > Your run-of-the-mill NVMe "gumstick" SSD by default will expose all of its > capacity in a single namespace (and I don't even think it can be configured > any other way), so you don't have to worry. > > Just remember that NVMe storage is always accessed through a namespace, so > the equivalent of good old /dev/sda is not /dev/nvme0 (the controller) but > /dev/nvme0n1 (the first namespace on the controller) > > > Or is it sufficient (and harmless for the SSD) to just > > partitioning and format the drive? > > It's not only harmless, it's the way it's supposed to be used. > > Remember that you will need to boot in UEFI mode, so you will need a system > partition (and you really, really want to use GPT). The gentoo handbook has > a good section on UEFI booting. > > > I found some hints regarding page sizes and erase block sizes > > when partitioning the drive. > > I wouldn't bother with that, but you're free to experiment :) > > andrea > Hi Andrea, yes...as long as other would take the risk I would suggest, they are free to experiment. ;) I encountered the next problem...and I will invite you to experiment together with me For my new system I choosed GPT/UEFI. I have a MSI Tomahawk MAX motherboard. This offers two boot modes: UEFI UEFI and Legacy Since my current system, from which I chroot into my new system is Legacu bootable I choosed the latter as boot mode. First (minor) trap: Despite being on a AMD64 system (and grub is installed accordingly) grub-install tries to access /usr/lib/grub/i386-pc/, which does not exist. I fixed that quick and dirty with a symlink lrwxrwxrwx 1 root root10 Apr 6 15:16 i386-pc -> x86_64-efi drwxr-xr-x 2 root root 24576 Apr 6 15:09 x86_64-efi Next: Calling grub-install --target=x86_64-efi --efi-directory=/boot results in: Installing for x86_64-efi platform. EFI variables are not supported on this system. EFI variables are not supported on this system. grub-install: error: efibootmgr failed to register the boot entry: No such file or directory. The config of the runnig kernel has set: CONFIG_EFI=y CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y CONFIG_EFI_VARS=y CONFIG_EFI_ESRT=y CONFIG_EFI_RUNTIME_MAP=y CONFIG_EFI_RUNTIME_WRAPPERS=y CONFIG_EFI_TEST=y CONFIG_EFI_PARTITION=y CONFIG_EFIVAR_FS=y Do I miss something here? ls -l /sys/firmware gaves me: drwxr-xr-x 5 root root 0 2020-04-06 16:25 acpi drwxr-xr-x 3 root root 0 2020-04-06 16:25 dmi drwxr-xr-x 21 root root 0 2020-04-06 16:25 memmap Do I really need an image on an USBstick to boot into UEFI mode just to setup a system to boot into UEFI mode? Is there any way around that? Cheers! Meino
Re: [gentoo-user] Quick question: Bootdevice nameing...
I'm assuming your subscription to this mailing list was unintentional, so you should just send an email to gentoo-user+unsubscr...@lists.gentoo.org. Am Montag, 6. April 2020, 16:13:16 CEST schrieb gary worley: > Hi > I keep getting a load of messages daily from this gentoo group. I must have > pressed something anyway do you know how I can stop getting all these > messages. Cheers > Gary > > -- > Sent from my Android phone with mail.com Mail. Please excuse my brevity. > On 06/04/2020, 15:09 Daniel Frey wrote: > > On 4/5/20 11:21 PM, tu...@posteo.de wrote: > > Hi, > > > > Currentlu my newly created system is installed on a harrdisk, which > > sit in a docking station connect via USB to my PC. > > > > The system is intended to be complete in the sense, that can > > boot bu itsself without accessing any other storage device. > > > > What is the most common behaviour here: > > If I change to boot sequence in the BIOS to boot the > > harddisk from the docking station...will it become /dev/sda ? > > > > Fstab depends on this... > > It's not supposed to, but in my direct experience, it can rearrange the > naming of the boot devices. > > I had to use PARTUUID in fstab/grub.cfg to get around this problem. > > Dan -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: Copying root to SSD in one go...a good idea...or?
On 4/6/20 9:35 AM, Grant Edwards wrote: On 2020-04-06, William Kenworthy wrote: Use rsync with the bwlimit option to slow down the overall data rate - monitor the temp with smart and slow it up if needed (I actually don't think you will have a problem.) Does bwlimit work with local copies? The man page says specifically it's for limiting bandwidthon sockets. -- Grant Can't you use the network syntax for one end of the rsync transfer to bring the socket controls into play? rsync source localhost:/path/to/dest Jack
Re: Re: [gentoo-user] Quick question: Bootdevice nameing...
HiI keep getting a load of messages daily from this gentoo group. I must have pressed something anyway do you know how I can stop getting all these messages. CheersGary-- Sent from my Android phone with mail.com Mail. Please excuse my brevity.On 06/04/2020, 15:09 Daniel Frey wrote: On 4/5/20 11:21 PM, tu...@posteo.de wrote: > Hi, > > Currentlu my newly created system is installed on a harrdisk, which > sit in a docking station connect via USB to my PC. > > The system is intended to be complete in the sense, that can > boot bu itsself without accessing any other storage device. > > What is the most common behaviour here: > If I change to boot sequence in the BIOS to boot the > harddisk from the docking station...will it become /dev/sda ? > > Fstab depends on this... > It's not supposed to, but in my direct experience, it can rearrange the naming of the boot devices. I had to use PARTUUID in fstab/grub.cfg to get around this problem. Dan
Re: [gentoo-user] Quick question: Bootdevice nameing...
On 4/5/20 11:21 PM, tu...@posteo.de wrote: Hi, Currentlu my newly created system is installed on a harrdisk, which sit in a docking station connect via USB to my PC. The system is intended to be complete in the sense, that can boot bu itsself without accessing any other storage device. What is the most common behaviour here: If I change to boot sequence in the BIOS to boot the harddisk from the docking station...will it become /dev/sda ? Fstab depends on this... It's not supposed to, but in my direct experience, it can rearrange the naming of the boot devices. I had to use PARTUUID in fstab/grub.cfg to get around this problem. Dan
Re: [gentoo-user] Quick question: Bootdevice nameing...
On Sun, Apr 5, 2020 at 11:21 PM wrote: > > Hi, > > Currentlu my newly created system is installed on a harrdisk, which > sit in a docking station connect via USB to my PC. > > The system is intended to be complete in the sense, that can > boot bu itsself without accessing any other storage device. > > What is the most common behaviour here: > If I change to boot sequence in the BIOS to boot the > harddisk from the docking station...will it become /dev/sda ? > It _might_ > Fstab depends on this... > With partitions labeled (with names or UUIDs) fstab will be happy Good luck, Mark
[gentoo-user] Re: Quick question: Bootdevice nameing...
On 2020-04-06, tu...@posteo.de wrote: > If I change to boot sequence in the BIOS to boot the harddisk from > the docking station...will it become /dev/sda ? No. The BIOS boot sequence has nothing to do with the order that mass storage devices are enumerated and named by the kernel. > Fstab depends on this... Then it's broken. For USB attached storage, you have to use UUID or LABEL for it to be reliable. -- Grant
[gentoo-user] Re: Copying root to SSD in one go...a good idea...or?
On 2020-04-06, William Kenworthy wrote: > Use rsync with the bwlimit option to slow down the overall data rate - > monitor the temp with smart and slow it up if needed (I actually don't think > you will have a problem.) Does bwlimit work with local copies? The man page says specifically it's for limiting bandwidthon sockets. -- Grant
Re: [gentoo-user] Preparing a blank NVMe as a boot drive...
Then there was something mentioned about namespaces, which should be allocated smaller than the physical drive Is this really needed - just to boot from this SSD? NVMe namespaces are an abstraction layer that allows a controller to present its connected storage as a number of independent volumes. Think LVM LVs, or the way a hardware RAID card presents volumes as multiple SCSI LUNs. Your run-of-the-mill NVMe "gumstick" SSD by default will expose all of its capacity in a single namespace (and I don't even think it can be configured any other way), so you don't have to worry. Just remember that NVMe storage is always accessed through a namespace, so the equivalent of good old /dev/sda is not /dev/nvme0 (the controller) but /dev/nvme0n1 (the first namespace on the controller) Or is it sufficient (and harmless for the SSD) to just partitioning and format the drive? It's not only harmless, it's the way it's supposed to be used. Remember that you will need to boot in UEFI mode, so you will need a system partition (and you really, really want to use GPT). The gentoo handbook has a good section on UEFI booting. I found some hints regarding page sizes and erase block sizes when partitioning the drive. I wouldn't bother with that, but you're free to experiment :) andrea
Re: [gentoo-user] Alternate Incoming Mail Server
On Mon, Apr 06, 2020 at 09:15:27AM -0400, Michael Orlitzky wrote: > All real MTAs follow the specification. A few email service providers > (think SendGrid, MailChimp, etc.) allow their users to configure how > many retries will be made, and every once in a while you have users who > set it to zero because they see a button and can't resist pushing it. > But those emails are never anything critical to begin with, in my > experience, and it's a rare problem nonetheless. Cheers for the help ! To be honest, I don't think I'd want to receive e-mail from someone who cannot resist pressing a button :) -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 9:08 AM, Ashley Dixon wrote: > On Mon, Apr 06, 2020 at 08:41:20AM -0400, Michael Orlitzky wrote: >> There's no need, the SMTP specification says that senders must retry >> every message, and should continue retrying for at least 4 or 5 days: >> >> https://tools.ietf.org/html/rfc5321#section-4.5.4 > > That's a relief, cheers. > > Excuse the skeptic within me, but is it safe to assume this specification is > strictly followed by all mail-transfer agents ? I.e., are there any common > M.T.A.s which do not continue trying to send for a few days ? > All real MTAs follow the specification. A few email service providers (think SendGrid, MailChimp, etc.) allow their users to configure how many retries will be made, and every once in a while you have users who set it to zero because they see a button and can't resist pushing it. But those emails are never anything critical to begin with, in my experience, and it's a rare problem nonetheless.
Re: [gentoo-user] SDD strategies...
(Hmm, weird, this failed to send and was laying around in my outbox.)
Am Samstag, 21. März 2020, 16:29:48 CET schrieb David Haller:
> Hello,
>
> On Sat, 21 Mar 2020, Marc Joliet wrote:
> >Am Mittwoch, 18. März 2020, 16:56:52 CET schrieb antlists:
> [..]
>
> >> Can't remember where it was - some mag ran a stress-test on a bunch of
> >> SSDs and they massively outlived their rated lives ... I think even the
> >> first to fail survived about 18months of continuous hammering - and I
> >> mean hammering!
> >
> >The German c't magazine did a similar test of various SSDs from
> >different
>
> I mentioned that in the other thread ("SDD, what features..."), I plan
> to sum up the articles tomorrow. I'd guess he means that test ;)
>
> >price categories, and they all showed the same result (I think some
> >exceeded their lifetime by more than a factor of two, and the minimum was
> >something like 1.5).
>
> If you mean TBW by "lifetime": All above factor 2, best: over 18. Ok,
> those were the "brand models" (1 Crucial, 1 OCZ (Toshiba), 2 Samsung
> and 2 Sandisk, and 2 drives of each model)...
Yes, that's what I meant (the SSDs are rated for an expected amount of data
written they can sustain, and apparently it's estimated very conservatively).
> Fun fact: one of the test PCs died and killed two of the 3 remaining
> SSDs, the second Sandisk Extreme Pro (the first had died already) and
> the first Samsung 850 Pro. The remaining second Samsung 850 Pro in the
> other Test-PC was still being hammered 4.5 months later with 8 PeBi
> written (all drives were 240/256 GB), but showing first "Uncorrectable
> Errors" via SMART.
>
> The test also included the failure mode as well, e.g. "dead as a
> brick" in a moment, warning signs via SMART, failure to write but
> still readable etc.
>
> The mag followed that up with a test of el-cheapo SSDs ... which I'll
> include in my summary.
Cool, I forgot most of the details (including that the test was split between
brand and cheapo models), so I'm looking forward to your summary!
> -dnh
Greetings
--
Marc Joliet
--
"People who think they know everything really annoy those of us who know we
don't" - Bjarne Stroustrup
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-user] Alternate Incoming Mail Server
On Mon, Apr 06, 2020 at 08:41:20AM -0400, Michael Orlitzky wrote: > There's no need, the SMTP specification says that senders must retry > every message, and should continue retrying for at least 4 or 5 days: > > https://tools.ietf.org/html/rfc5321#section-4.5.4 That's a relief, cheers. Excuse the skeptic within me, but is it safe to assume this specification is strictly followed by all mail-transfer agents ? I.e., are there any common M.T.A.s which do not continue trying to send for a few days ? After my thankfully-brief experience with the likes of Microsoft and their Exchange program, I always question how much impact the content of an R.F.C. actually has on an implementation. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] how do you monitor your pc?
Am Donnerstag, 2. April 2020, 13:29:06 CEST schrieb Caveman Al Toraboran: [...] > * another shows `watch 'dmesg -T` for kernely > things not showing up in `journalcdl`. [...] Don't "journalctl -k" and "journalctl -t kernel" accomplish the same thing, though? (I mean, I also use "dmesg -T" on occasion because it's quicker, I'm just curious.) Greetings -- Marc Joliet -- "People who think they know everything really annoy those of us who know we don't" - Bjarne Stroustrup signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Alternate Incoming Mail Server
On 4/6/20 8:35 AM, Ashley Dixon wrote: > > What do you think; is this at all possible ? Has anyone here done anything > like > this before ? > There's no need, the SMTP specification says that senders must retry every message, and should continue retrying for at least 4 or 5 days: https://tools.ietf.org/html/rfc5321#section-4.5.4 Your incoming mail will arrive whenever the server comes back up. We regularly reboot our MX in the middle of the day and no one notices. Whatever solution you'd come up with to solve this problem will cause more downtime than that =)
[gentoo-user] Alternate Incoming Mail Server
Hello, After many hours of confusing mixtures of pain and pleasure, I have a secure and well-behaved e-mail server which encompasses all the features I originally desired. However, in the event that I need to reboot the server (perhaps a kernel update was added to Portage), I would like to have a miniature mail server which catches incoming mail if, and only if, my primary server is down. I have Gentoo installation on an old Raspberry Pi (model B+), and was curious if such a set-up was possible ? I also want the solution to be as minimal as possible. I see the problem as three parts: (a) Convincing the D.N.S.\ and my router to redirect mail to the alternate server, should the default one not be reachable; (b) Creating the alternate mail server to be as lightweight as possible. I'm not even sure if I need an S.M.T.P.\ server (postfix). Would courier-imap do the trick on its own (with courier-authlib and mysql) ? (c) Moving mail from the alternate server to the main server once the latter has regained conciousness. I realise this is a slightly different problem, and is not even necessarily _required_ for operation, although it's certainly a nice-to-have. What do you think; is this at all possible ? Has anyone here done anything like this before ? Thanks in advance. -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
[gentoo-user] Preparing a blank NVMe as a boot drive...
Hi, I read quite some stuff of the more general kind about NVMe, the technoloy etc...and would not state to be sure of haveing understood all that ... Currently I have installed (physically) a NVMe drive, which is unaltered and in the state as the company has delivered it. This drive should become my boot drive with a complete root system. I read something about NVMe-fabric which seems to me like a network enable access to that drive, which I don't need. Then there was something mentioned about namespaces, which should be allocated smaller than the physical drive. Is this really needed - just to boot from this SSD? Or is it sufficient (and harmless for the SSD) to just partitioning and format the drive? Anything different than handling a harddisk? Addtionally here https://wiki.gentoo.org/wiki/SSD I found some hints regarding page sizes and erase block sizes when partitioning the drive. On several page in the internet I read, that this is "old magic"...the problems do no longer appear, since the controller of the SSD maps all that to the physical NAND by itsself. Currently I got confused and want my diesel driven calculator back. ;) Cheers! Meino
Re: [gentoo-user] ...recreating exactly the same applications on a new harddisc?
On Sunday, 5 April 2020 20:39:47 BST Neil Bothwick wrote: > On Sun, 05 Apr 2020 19:08:24 +0100, Peter Humphrey wrote: > > > I wonder, would there ever be any valid reason to have the E.S.P.\ > > > and /boot as different partitions ? > > > > I found I had to do so. I couldn't get Neil's prererred layout to work. > > I forget the details now, but I only managed to build a usable system > > by leaving a small unformatted partition before the VFAT /boot > > partition. The first partition is marked bios_grub and the second > > 'boot, esp'. > > > > I did try later to combine the two, but I still couldn't get it to > > work. Perhaps the BIOS has something odd in it. > > If you are using a BIOS system, you need the compatibility partition at > the start. If you are using UEFI it shouldn't be necessary. No, I know, but it is - unless I'm doing something daft, of course. -- Regards, Peter.
Re: [gentoo-user] portage: how to inhibit binary distribution
On Thursday, April 2, 2020 1:33:08 PM CEST n952162 wrote: > (I see that /var/db/pkg/app-crypt/gnugp*/CONTENTS has ...) > > On 2020-04-02 13:30, n952162 wrote: > > I see that /var/db/pkg/app-crypt/gnugp* has > > > > /usr/bin/gpg > > > > I re-emerged that, thinking maybe packages on the stage3 CD are > > binaries, but I still have /usr/bin/gpg in that file, with the same md5 > > as is really in /usr/bin/gpg. I thought gentoo distributed sources ... > > well, it does - the emerge compiled up a storm. But the binary is as > > delivered. If the sourcecode and compile-options have not changed, I would expect the resulting binary to be identical as well. Why do you expect the binary to have a different checksum? -- Joost
Re: [gentoo-user] Re: Why busybox?
> > > Why does portage insist on installing busybox for me? > > > > BusyBox is just a minimal set of utilities which would be useful for > > rescuing a system, or to be used on an embedded system with extreme > > limitations. There's not really any reason to remove this, but if you > > insist... > > As for rescue scenarios, that has been obsolete for a long time. For at > least 10 years now, whenever I need to rescue myself I boot from a > separate medium that is normally offline, a CD, an SD card or a thumb > drive. > If your breakage can be fixed by busybox, then its easier, faster and avoids downtime when compared to booting from alternate media. As its statically linked, it will still run if any libraries required by the conventional binary are stuffed (BTDT). Of course, sometimes its not enough and you will have to fall back to booting from alternate media. I don't think many will find a compelling case for its removal.
Re: [gentoo-user] repoman the optimist
On Sun, 5 Apr 2020 20:57:28 -0700, Ian Zimmerman wrote: > I am preparing some home made ebuilds and I run "repoman manifest" as > part of the process. repoman downloads the upstream tarball for the > package from the SRC_URI location, but only after trying the distfiles > directory on all servers in my PORTAGE_MIRRORS. This software is not > packaged by gentoo, so this always fails and it amounts to a useless > delay for me, and perhaps an annoyance for the servers. How can I > disable it and make repoman go straight to the upstream location? You could put RESTRICT=mirror in the ebuild, or possibly in package.env -- Neil Bothwick If Yoda so strong in force is, why words in right order he cannot put? pgpxWilwOmKga.pgp Description: OpenPGP digital signature
Re: [gentoo-user] Quick question: Bootdevice nameing...
tu...@posteo.de wrote: > Hi, > > Currentlu my newly created system is installed on a harrdisk, which > sit in a docking station connect via USB to my PC. > > The system is intended to be complete in the sense, that can > boot bu itsself without accessing any other storage device. > > What is the most common behaviour here: > If I change to boot sequence in the BIOS to boot the > harddisk from the docking station...will it become /dev/sda ? > > Fstab depends on this... > > Cheers! > Meino Have you ever considered using either LABELS or UUIDs in fstab? I use LABELS for most everything here. To be honest tho, LABELS can be duplicated in certain situations. UUIDs are much less likely to have that happen and are the better choice. Using either of those means it doesn't matter how things are connected, it should still work. If you use grub2, I think it uses UUIDs too. I'm not certain but I think it does. If it does, booting won't be a problem either. Someone correct me if I'm wrong on that tho. Just a thought. Dale :-) :-)
Re: [gentoo-user] repoman the optimist
Using RESTRICT="primaryuri" inside the ebuilds (unfortunately doesn't work as an environment variable). Beware that's planned to be deprecated. Someone suggested setting an empty mirror string as an environment variable but I had no success. Il Lun 6 Apr 2020, 05:57 Ian Zimmerman ha scritto: > I am preparing some home made ebuilds and I run "repoman manifest" as > part of the process. repoman downloads the upstream tarball for the > package from the SRC_URI location, but only after trying the distfiles > directory on all servers in my PORTAGE_MIRRORS. This software is not > packaged by gentoo, so this always fails and it amounts to a useless > delay for me, and perhaps an annoyance for the servers. How can I > disable it and make repoman go straight to the upstream location? > > -- > Ian > >
[gentoo-user] Quick question: Bootdevice nameing...
Hi, Currentlu my newly created system is installed on a harrdisk, which sit in a docking station connect via USB to my PC. The system is intended to be complete in the sense, that can boot bu itsself without accessing any other storage device. What is the most common behaviour here: If I change to boot sequence in the BIOS to boot the harddisk from the docking station...will it become /dev/sda ? Fstab depends on this... Cheers! Meino
Re: [gentoo-user] Copying root to SSD in one go...a good idea...or?
On 6/4/20 1:12 am, tu...@posteo.de wrote: Hi, currentlu I am preparing a new Gentoo Linux by compiling all the application I had on my old system. Due to delivery problems (corona) my SSD was delivered today (or yesterday...it depends...;) . When the whole compilation has finished and the system boots it needs to be transfered to the SSD. The SSD has a heat spreader...so it gets hot, when used. Is it wise to copy the whole root system to the SSD in one go in respect to a not so healthy heat increase? And if not...how can I copy the root system in portions to the SSD and do not miss anything? Are there SDD-friendly and SSD-unfriendlu methods of copying greater chunks of data to a SSD (rsync, tar-pipe, cp)? What is recommended here? Thanks a lot for any help for a SSD newbie in advance! Cheers! And stay heathy! Meino Use rsync with the bwlimit option to slow down the overall data rate - monitor the temp with smart and slow it up if needed (I actually don't think you will have a problem.) BillK
