Re: [GLLUG] British Gas DKIM failure?
"It's quiet. It's too damn quiet..." On 09/07/2024 01:13, Steve Parker via GLLUG wrote: Just noticed that the last I heard from this group was in March. Has it been unusually quiet, or am I missing out? On 31/03/2024 18:12, Henrik Morsing via GLLUG wrote: Hi again, I just installed the DKIM Verifier extension to Thunderbird on my laptop and that fails the email as well. My laptop has OpenSSL 3.1.4, so that has the bug as well. Still no closer to fixing this though. Regards, Henrik Morsing On Sun, Mar 31, 2024 at 03:30:47PM +0100, Henrik Morsing via GLLUG wrote: Hi all, Happy Easter. I have some days off, so finally had some time to look at this. Having disabled rejection in January gave me some more data to look at and it became obvious that anyone using 1024-bit keys failed the check and anyone using 2048-bit passed. I found one person out there who said his DKIM checks started failing on 1024-bit keys after he upgraded from OpenSSL 0.9.8 to 1.1.1 (My current version) but sadly no replies. So, my OpenSSL has a bug, I assume, but it's not really publicly known and no-one seems very concerned about it? Seem very odd. Tried to find somewhere in the configuration where a limit was set but couldn't find anything and also find it odd if that was the case. Regards, Henrik Morsing On Fri, Jan 12, 2024 at 03:48:17PM +, Henrik Morsing via GLLUG wrote: Good afternoon, Not dircetly Linux, sorry, but British Gas has spent the last year sending me letters saying they can't email me. When I look into it, their emails are rejected based on a bad DKIM signature. The problem is, not receiving the email, how can I find out what the problem is? mxtoolbox says their setup is fine, but that surely can't check the signature inside one of their emails. What is slightly odd is that DMARC policy is set to none, so shouldn't reject anything anyway. I can't say I'm a DKIM/DMARC expert, but this is what I see: Dec 22 12:37:12 emil opendkim[768]: 2F7612233E: s=mailjet d=britishgas.co.uk a=rsa-sha256 SSL error:04091068:rsa routines:int_rsa_verify:bad signature Dec 22 12:37:13 emil opendmarc[3858740]: 2F7612233E: britishgas.co.uk fail Dec 22 12:37:13 emil postfix/cleanup[3996586]: 2F7612233E: milter-reject: END-OF-MESSAGE from o94.p12.mailjet.com[87.253.237.94]: 5.7.1 rejected by DMARC policy for britishgas.co.uk; from=<296f63a1.caaabphwdncaakg7asyaaycquv4aabbdggblh...@a1065858.bnc3.mailjet.com> to= proto=ESMTP helo= Not sure where to go from here though. Smells like their problem to me, but I don't want to tell them that without proof. Any hints? Regards, Henrik Morsing -- -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug -- -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Using LLM for support answers - please don't (Was Re: British Gas DKIM failure?)
On 28/01/2024 14:37, Jan van Bergen via GLLUG wrote: Let's try to be nice to each other, especially when somebody is doing his/her/its best to help +1 -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] British Gas DKIM failure?
On 27/01/2024 18:08, Henrik Morsing via GLLUG wrote: I'm now getting the same from the Land Registry: I wish there was a test I could do to check what is actually wrong... Okay, so this would indicate that it is more likely something wrong at your end rather than at theirs. I think that this point, I would start to wonder if there is anything at your end that is altering the email before it gets to the DKIM check. So, I suggest you check good DKIM signatures against "bad" DKIM signatures, and look at which headers are being used to create the signature (the "h" in the DKIM header) and see if there is a patterns. On an email directly from me, you would see "h=Date:Cc:Subject:To:References:From:In-Reply-To:From;" in the header. Maybe something in your system is altering something in a field that is being used by the British Gas and Land registry emails, like adding an "EXTERNAL" into the subject line before the DKIM test? Regards Marco -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] British Gas DKIM failure?
Hi, So looking at this, and Andy's email with what he sees, it looks like his British Gas emails are coming from a different place to yours. His are coming from SalesForce, and yours are coming from Mail Jet, so I don't think we can draw much from that. I think the next thing to look at is maybe this is an SSL issue, so I found thse: https://github.com/openssl/openssl/issues/8010 https://portal.microfocus.com/s/article/KM15515?language=en_US That would indicate a possible issue within some Intel Goldmont processors, and can be fixed with telling OpenSSL not to use the hardware for this Maybe that is worth looking in to. Regards, Marco On 12/01/2024 18:28, Henrik Morsing via GLLUG wrote: On Fri, Jan 12, 2024 at 04:20:34PM +, Marco van Beek via GLLUG wrote: Hi, I suggest grepping your logs for "2F7612233E" as that should pull up all the the info related to that email from the point Postfix accepts the connection until it closes, and see if that tells you some more. Regards, Marco Hi Marco, This is what I see: Dec 22 12:37:12 emil postfix/smtpd[3996527]: 2F7612233E: client=o94.p12.mailjet.com[87.253.237.94] Dec 22 12:37:12 emil postfix/cleanup[3996586]: 2F7612233E: message-id=<296f63a1.caaabphwdncaakg7asyaaycquv4aabbdggblh...@mailjet.com> Dec 22 12:37:12 emil opendkim[768]: 2F7612233E: o94.p12.mailjet.com [87.253.237.94] not internal Dec 22 12:37:12 emil opendkim[768]: 2F7612233E: not authenticated Dec 22 12:37:12 emil opendkim[768]: 2F7612233E: s=mailjet d=britishgas.co.uk a=rsa-sha256 SSL error:04091068:rsa routines:int_rsa_verify:bad signature Dec 22 12:37:12 emil opendkim[768]: 2F7612233E: bad signature data Dec 22 12:37:13 emil opendmarc[3858740]: 2F7612233E: britishgas.co.uk fail Dec 22 12:37:13 emil postfix/cleanup[3996586]: 2F7612233E: milter-reject: END-OF-MESSAGE from o94.p12.mailjet.com[87.253.237.94]: 5.7.1 rejected by DMARC policy for britishgas.co.uk; from=<296f63a1.caaabphwdncaakg7asyaaycquv4aabbdggblh...@a1065858.bnc3.mailjet.com> to= proto=ESMTP helo= Regards, Henrik Morsing -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] British Gas DKIM failure?
Hi, So first of all, as far as I can see, British Gas's DMARC policy is set to "reject". BUT, the email is actually coming from MailJet, from the limited info below. I think what you need to check if you can, is what the name of the DKIM signature they are using actually is, and maybe that will give you some more info. I also can't see any reference to MailJet in their SPF, but my guess is that they are using MailJet in the envelope and then British Gas in the header. And no, what MX toolbox can do in terms of DKIM is limited. It can look up the key, but that is about it. The DKIM tester I use require you to send them a test email, which you can't do. So yes, there is a DKIM key for mailjet in their DNS, but no idea if they are using it correctly. I suggest grepping your logs for "2F7612233E" as that should pull up all the the info related to that email from the point Postfix accepts the connection until it closes, and see if that tells you some more. Regards, Marco On 12/01/2024 15:48, Henrik Morsing via GLLUG wrote: Good afternoon, Not dircetly Linux, sorry, but British Gas has spent the last year sending me letters saying they can't email me. When I look into it, their emails are rejected based on a bad DKIM signature. The problem is, not receiving the email, how can I find out what the problem is? mxtoolbox says their setup is fine, but that surely can't check the signature inside one of their emails. What is slightly odd is that DMARC policy is set to none, so shouldn't reject anything anyway. I can't say I'm a DKIM/DMARC expert, but this is what I see: Dec 22 12:37:12 emil opendkim[768]: 2F7612233E: s=mailjet d=britishgas.co.uk a=rsa-sha256 SSL error:04091068:rsa routines:int_rsa_verify:bad signature Dec 22 12:37:13 emil opendmarc[3858740]: 2F7612233E: britishgas.co.uk fail Dec 22 12:37:13 emil postfix/cleanup[3996586]: 2F7612233E: milter-reject: END-OF-MESSAGE from o94.p12.mailjet.com[87.253.237.94]: 5.7.1 rejected by DMARC policy for britishgas.co.uk; from=<296f63a1.caaabphwdncaakg7asyaaycquv4aabbdggblh...@a1065858.bnc3.mailjet.com> to= proto=ESMTP helo= Not sure where to go from here though. Smells like their problem to me, but I don't want to tell them that without proof. Any hints? Regards, Henrik Morsing -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IPv6 address allocation changes
On 24/07/2023 22:12, Andy Smith via GLLUG wrote: Hello, On Mon, Jul 24, 2023 at 12:19:39PM +0100, John Hearns via GLLUG wrote: Is it a shaggy dog story that the CIA own the Class A 10.X.X.X block? I doubt there is any factual evidence regarding this that could be looked up in literally seconds, so sure, why not? Regards, Andy I once managed to convince someone who really should have known better that there was a "hidden" subnet bit that allowed you access to all of the private IP ranges anywhere in the world, bypassing NAT Of course having told them, I then I had to kill them :-) -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Comments please
Hi All, So my opinion on this is that the NHS's greatest IT weakness (the diversity of systems) is also it's greatness strength. Every "solution" i have read about over the last 10 or 15 years appears to be a 20th century solution for a 19th century problem, and what is needed is a 21st century approach. I believe it doesn't "need" an open source solution, it needs a common approach, like a set of RFC's, that allows everyone, closed and open source together, to move in the same direction, and by the very nature of the approach, be able to safely share data without a need to centralise it. There are at least two sets of unique ID's floating around, National Insurance numbers and NHS numbers, and then there is a need to cater for people who don't have either, or who do but have just been dragged out from under a bus and annoyingly for some, cannot answer those sorts of questions until after they are treated. There lots of really good examples of distributed databases. LDAP and DNS come instantly to mind. You just need an indexing system that is versatile enough to work with the idea that some people are going to have multiple entries, and in an ideal world they would eventually all get merged, but life isn't like that. Having different systems means not having common exploits. There are regular stories in the press about hospitals getting their systems hacked and/or data encrypted. You really don't want them all to be the same and all get hacked at the same time. I would start by identifying every data set you need as a healthcare provider, e.g. patient personal data, appointment data, pharmaceutical inventory, stock control, staff records, and so on, and create a set of minimum requirements that would go on to create a common API definition. Then you make that legally binding for all new software purchases, including support/subscription renewals. If an original software provider either won't do it, can't do it, or has gone out of business, then you create a market for third party tools, and just like the NHS has the ability to force pharmaceutical patents into the public domain, it could force that software to open up it's source code, at least to those third parties plug-in providers. As time goes on, the API gets revised, improved and updated in the RFC's. All this software could be closed source or open source, but they would all have to talk to each other, so while the source may be closed, the market isn't, and can't be, closed. Anyway, that's just my opinion. You did ask :-) Cheers all, Marco -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Caution with recruitment agencies
The whole IR35 shell company is a bit of a minefield. I guess from what you are saying, technically you become an employee of TEK systems, and therefore have some degree of employee protection, at a minimum wages form the official start date until the end of whatever notice period would have been in the contract, so maybe three to four weeks worth of money. Sounds like you need an employment lawyer if you want to get any further as TEK will no doubt deny all responsibility. But as the previous poster inferred, did you actually sign a contract? If not, then you are down to inferred terms of employment, which might actually count in your favour. Cheers, Marco On 08/06/2023 21:17, James Tobin via GLLUG wrote: On what date did you sign a contract that stated you would start on 15 May 2023? On Thu, 8 Jun 2023 at 21:00, Martin A. Brooks via GLLUG wrote: Even after 20-odd years as a contractor, you can still be surprised by recruitment agencies. A contract recently blew up on me in a new and exciting way, here's the story: https://blog.hinterlands.org/2023/06/when-contract-hunting-goes-wrong-teksystems-allegis-group/ -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Host for my business and music band colaboration via Jitsi and BB over single domain
Hi, I might be able to help. I am an ex-concert touring crew person and have my own hardware in a server farm in the UK for which we do web and email hosting, amongst other things. Cheers, Marco On 24/05/2023 18:20, MJ via GLLUG wrote: Dear Yall! is there a bunch of peeps I should entrust my life in this subject matters above. I hope to have my own Jitsi, Wordpress or and Concrete9 instals. With Thanks. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Roll-out of FTTP / FTTH
This is called SoGEA (Single Order Generic Ethernet Access). You get a ADSL package that included the bit of copper and usually costs about £5 more that a standard ADSL line but you don't pay for an analogue line any more. It also isn't connected to a voice port at the exchange either. It does, however, make the broadband provider responsible for the bit of copper so none of that bouncing between suppliers when the line is of poor quality and everybody blames everybody else. Anybody with a combined analogue line and broadband is goign to get a call at some point from one of both of their providers about converting to SoGEA and VOIP. Cheers, Marco On 12/04/2023 15:06, Peter Grant via GLLUG wrote: I have a copper line with data provision but not telephone -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] sendmail puzzle
Hi, It might be the difference between a missing entry in a zone file, and a missing zone file. Maybe it is the lookup mechanism that fails, rather than it checking the IP address itself. It might be another rule set that is trying to do a reverse lookup (eg hostname), and it barfs out at that point. Maybe increase the logging verbosity and check the logs again? Cheers, Marco On 10/10/2022 22:54, Ken Smith via GLLUG wrote: I'm trying to sort out a Rocky 8.5 server that has sendmail installed. (Please don't go on a diversion about how I should tell the owner to dump sendmail and switch to exim or postfix - save that for another thread please. ) I'm pretty good with sendmail but this problem has me a bit foxed. I'd value some suggestions of where to look as I think I'm not seeing the wood for the trees. It will send from addresses in the local network, without auth, because I have "connect:192.168.123 relay" in the access file - that being the local LAN. I've tested sasl auth and that is authenticating. Using telnet from an IP off their LAN (over a VPN) I can connect using TLS (openssl s_client etc etc) and authenticate (perl -MMIME::Base64 etc etc) it accepts my credentials and then if I try to send a message I get "Relaying denied. IP name lookup failed [my local ip]" The same happens with a test using Thunderbird. If I do the same test from the host that sendmail is on, it works fine. Also if I do the same test from another host on the same LAN it works fine. Somehow its complaining about the source IP in authenticated sessions outside the LAN range. In the test from my local LAN (172.16.0.x), over a VPN, the remote dns can't resolve the reverse dns of my LAN. I've done a similar test with another sendmail site and remote auth is working fine. Maybe sendmail is doing reverse DNS when it shouldn't be. Suggestions most welcome Thanks Ken -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] RAM testing question
Hi, Does anyone know of a multi-type RAM test card / box? I have a load of RAM that has been pulled out of boxes over the years, and is probably all good, but short of finding a motherboard of the right match for each type of RAM, and then running MemTest, I have no idea. I have found various adapter cards like DDR2 to DDR3 and so on, but what I am really after was some sort of external box with a load of DDR sockets which plugs into some sort of internal PCI card or USB port. Does anyone know of such a device, or a name / better description I could use to search for one? Cheers, Marco -- Marco van Beek == Supporting Role Ltd. Grove Park Studios, 188-192 Sutton Court Rd, London, W4 3HR == T: 020 3432 0300 M: 0788 770 3604 E: mvanb...@supporting-role.co.uk W: http://www.supporting-role.co.uk/ == Company Registered in England No. 03658568 == -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] scam phone call
any number of digits are possible, but apparently there is a standard that says the minimum is 7 and the maximum "should not exceed" 15, and the nation part should not exceed 12. Then apparently you can add additional codes for the system at the far end, which all adds up to a potential maximum of 24. Boy, am I looking for any excuse not to finish looking at CV's for new staff... :-) On 30/09/2021 17:27, Chris Bell via GLLUG wrote: So a 13 digit number is possible? -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] scam phone call
Except of course we in the UK have a really rubbish level of security on setting CallerID and is almost entirely down to trust and the person in charge of the phone system. Apparetnylthis will all change after 5G is rolled out but I have no idea why this is the case. So there is a fair chance some poor Dutch person is getting a lot of complaints on his mobile and has no idea what they are talking about. Cheers, Marco van Beek On 30/09/2021 17:08, Jan van Bergen via GLLUG wrote: Hi Chris 0031 is a call from the Netherlands. In this case as the first number of the user is a 6 it would be a Dutch mobile calling you. It would not be an IP as the dutch use a special range for it. Any number starting with 003 or 004 is coming from a European caller. (see full list e.g. here https://warwick.ac.uk/services/academicoffice/ourservices/saro/recruitment/callingcampaign/callingcodes/) Jan On 30/09/2021 16:58, Chris Bell via GLLUG wrote: Hello, I have received a scam telephone call to my landline and caller display shows the caller as 0031625679475, a 13 digit number. Is this likely to be a genuine number from something like an IP digital phone? My sister has received several similar calls with long numbers starting with 003 -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IT does cost
On 11/08/2021 11:57, Iain M Conochie via GLLUG wrote: actual software used. Project management that delivers in one big bang is a Have a look how the DVLA have been able to move their IT forward, so we can now * Tax vehicles online * Transfer ownership online * No longer having to display Tax disks on your cars I understand the last one can be contentious due to privacy issues, but the point remains. Iain Evolution not revolution. Works every time but it's a pig to market and sell because if you do it right nobody really notices. Cheers, Marco -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IT does cost
On 06/08/2021 12:30, Chris Bell via GLLUG wrote: What warranty comes with Microsoft other than you can pay someone to look at the problem? There is a corporate entity that can be taken to court. Blame is not about warranty, it's about anyone other than me being to blame. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] IT does cost
Hi Chris, I think this is a fairly poorly written article form a technical point of view, which is fine. It is just highlighting us to the costs, not the why's. First of all, Microsoft agreed a pricing package to continue to support Windows XP for the likes of the NHS. If I remember correctly this had to be done due to their software only running on IE6, so moving all those computers to open source would not fix the problem. And the NHS has a dreadful history in regards to IT projects, and has wasted far more in failed projects that the costs of supporting the old systems. Secondly, Government seem far happy outsourcing the whole problem to systems like Office 365, despite legal issues like the US CLOUD act that in theory would give US Federal agents the right to access HM Gov's data if they could persuade a US judge to sign a warrant. Thirdly, open source software comes with no warranty, and that scares civil servants who want someone else to blame. To be brutally honest, the problem is between keyboard and chair. At all levels. We are not just talking about contracts being handed to companies with a history of past failures, but also a complete lack of understanding at policy level of what could, and should be done. And there is an upside to that. If Government actually got their act together they could actually spot so many crimes financial simply by linking everybody's records together and looking at what doesn't add up and applying Unexplained Wealth Orders. Of course, my inner conspiracy theorist says that is why they haven't got their act together, but that's a rabbit hole for a different day... Even just the simple rule that all government issued documents should be in ODF, and all software should be ODF compliant is ignored by pretty much everybody. I was on the Land Registry site the other day. Could not find a single ODF version of a form. Even one that dates form 21 June 2021 is in Word format. It's either ignorance or incompetence. Mr Wall, meet Head. Head, meet Brick Wall. As someone who has clients who have to fill in IT audit forms to work with government bodies (and I include bodies like the NHS in that description) I am appalled at the level of incompetence, like emailing my a macro-filled Excel spreadsheet. Like I am really going to open that. And being asked how I check my tape backups. Yes, really. It is but a small window into those people's day to day lives, some of whom think tape backups are still a regular thing in the real world. I once had a conversation with a major ministerial insider about CE marking and applying it to software That there should be the same sort of requirements to comply with standards as a fridge or washing machine. I was told it was a trading standards issue. They did not see the problem of software claiming to but not actually complying to well established and published standards. I mean I am talking about basic things like SMTP in network scanners missing whole chunks of the standard, and therefore having to hack your mail server to accept the botched headers. Oh dear, this seems to have turned into a rant... :-) Marco On 06/08/2021 11:17, Chris Bell via GLLUG wrote: Hello, https://www.bbc.co.uk/news/uk-politics-58085316 is an article about the £2.3bn government spend on patching old computers and systems compared with the £4.7bn total government IT spend. There are also several comments below. I do not know how much is spent on desktop system replacement, but there is an argument raging about the security aspects and costs of writing replacement or upgraded software systems. There is one comment about existing specialised hardware such as an MRI scanner built by a company that no longer exists but would be extremely expensive to replaced, (although replacement FOSS may already exist). I am not a developer, but would be interested in the implications and costs of writing and maintaining government software systems using Free Open Source Software compared with Microsoft. I assume that high level languages could be used, and I know what I would prefer, but that does not always convince the decision makers who are probably not IT experts. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
[GLLUG] Full time vacancy
Hi All, I have an opening that could suit a bright young kid initially to help with desktop support but with the intention of training them up to do server support, both Linux and Windows, as well as lots of networking and stuff. Happy to talk to someone who has no formal training, perhaps let down by the education system or are having problems getting jobs due to some lifestyle or fashion choices... All I am after is that they have a decent brain, are trustworthy, can think logically, and are eager to learn. Starting pay would be £24K a year for the right person, and they need to have commuter access to the London area. Most of our clients are accessible via public transport. Cheers, Marco. -- Marco van Beek == Supporting Role Ltd. Grove Park Studios, 188-192 Sutton Court Rd, London, W4 3HR == T: 020 3432 0300 M: 0788 770 3604 E: mvanb...@supporting-role.co.uk W: http://www.supporting-role.co.uk/ == Company Registered in England No. 03658568 == -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] BEST NIX-BASED ROUTER
On 17/06/2021 13:27, Martin A. Brooks via GLLUG wrote: You were wrong the moment you decided that writing a filesystem was a good idea. Ouch. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] BEST NIX-BASED ROUTER
We have a different methodology where the live server initiated the backup, but once each set is completed completed sets a flag on the backup server and the backup server then takes a copy using hard links, so that allows us to have a whole bunch of historical copies that cannot be accessed via the live server. Also, the live server only has a restricted shell on the backup server so can only run a limited set of commands, and is chrooted to it's own home directory. Pros and cons to both methods, but both have the same end result as far as ransomware access is concerned. Regards, Marco On 16/06/2021 18:40, John Winters via GLLUG wrote: On the backups front, I have long felt that for secure backups it is essential that the backups are driven by the backup server. The backup server establishes a connection to the live server and backs up what it is configured to back up. The live server must have no access to the backup server, nor means to establish a connection to it. If your backups are driven and controlled from your live server, then as soon as it is compromised the attacker has the option to modify what backups happen, or even prevent them entirely. If the live server has some kind of write access to the backup server then they can go on and compromise all your existing backups too. If the backup server is the one initiating the backup but runs no externally accessible services, then it does a backup when it is configured to do a backup. If the live server has been compromised to the point where the backup server can't, then it can report the fact. No amount of corrupting the files on the live server will affect those on the backup server. Of course you still need a suitable cycle of backups so you can go back as far as is necessary to recover. I have two backup servers in different locations which do fairly comprehensive backups each night. When they're not doing that, they're switched off which makes them even harder to crack into. John -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Best NIX-based router/software for a small business network
On 15/06/2021 20:45, James Courtier-Dutton via GLLUG wrote: So, the best defense is using a backup system that cannot be attacked by a Ransomware attack. And your second line of defence is a second backup system that cannot be attacked by a Ransomware attack... For the third, maybe a local backup using a system that does not rely on the OS mounting a drive, and then I would probably put #4 as some really good granular share, file and folder permissions that limits what any one person can do to the system, as that also helps to protect against disgruntled employees getting nasty. A firewall is very far down my list. And for it to be of any use in this scenario it really does need some form of proxy with a URL blacklist subscription, and you probably already get that with the decent anti-virus solution you should have already bought by this point... Regards, Marco -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Best NIX-based router/software for a small business network
Don't think a firewall / router is going to give you any sort of protection against ransomware attacks. Even if is able to block dodgy sites it's of little use against that memory stick someone just dropped. Regards, Marco On 15/06/2021 18:12, gvim via GLLUG wrote: Didn't OpenWRT have some security holes a while back? I'm trying to sell clients on a first line of defence against potential ransomware attacks so I need something rock solid. gvim On 14/06/2021 17:02, Travis Mooney via GLLUG wrote: There are off the shelf OpenWRT routers. I use: * Turris Omnia as edge routers: https://www.turris.com/en/omnia/overview/ * GL iNet Convexa-B as access points Both work well, and are native OpenWRT solutions. The Omnia is a bit expensive, but you could just stick with GL iNet devices if cost is a problem. Kind regards, travis On 14/06/2021 16:56, Peter Grant via GLLUG wrote: On Mon, 14 Jun 2021 at 16:43, Martin A. Brooks via GLLUG mailto:gllug@mailman.lug.org.uk>> wrote: On 2021-06-14 15:42, gvim via GLLUG wrote: > With ransomeware becoming a threat to both small and large businesses > I'm inclined to advise small businesses to change their router as a > first line of defence. What is currently the best NIX-based > router/software? pfSense? If I was installing such a thing at a customer site I would first suggest a reasonable off the shelf product rather than a custom built black box. I have run pfsense very happily at work (and home) for many years - it's nicely comprehensive and easy to use. Netgate (owners of pfsense) make some devices with pfsense preinstalled, which I can't speak from much experience with. Until we moved office and I got the budget to replace it, we have an old Pentium dual core Dell desktop running pfsense. Peter -- ** Travis Mooney-Evans tra...@mooney-evans.com +447908631440 Skype: ttmooney -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Power control over IP
As many others have already said. the ideal is if this is part of the baseboard management tool of the servers. Although both DELL and HP call it by their own names (and often charge extra for additional features) the generic term is IPMI, or Intelligent Platform Management Interface (https://en.wikipedia.org/wiki/Intelligent_Platform_Management_Interface). However, you do have to buy servers that support this, but it gives you a lot of control, and is a lot cheaper that a compilation of a networked KVM and a networked PDU. In most cases it is brought out as a separate Ethernet port on the back of the server, which means you can run it on a completely separate network should you wish for security purposes. IPMI systems usually includes the ability to boot of remote media, like the CD-ROM of your own computer, so you can analyse (and often fix) corrupt boot drives without leaving home. As long as you have power to the server (and the switch the IPMI is plugged in to, of course), you have the ability to start fixing it. These days when I buy a new server, we never even plug a screen or keyboard in to it. We just do enough of the install over the KVM interface that comes with the IPMI system, and then carry on with SSH as an when the server is booted. Even without a license the HP "integrated Lights Out" system will still allow basic troubleshooting until the OS boots. I haven't played with Dell's system, but I am sure someone on the list can confirm. We use SuperMicro servers and if you get a motherboard with IPMI, they come fully featured. So I suggest looking on the back of the servers you already have and see if there are any unexplained Ethernet ports, usually located in a different place to the main Etherports the OS uses. As some else said, maybe you already have some servers with the functionality you need. Regards, Marco On 29/05/2021 16:19, stuart taylor via GLLUG wrote: Hi all, During the past 15 months I have managed to change various things involving our systems, for the better I think. We have also gained various part time volunteer admins, who are very good, mostly better than I am. One of them showed me how he could power down his servers remotely over IP, and restart them again. This looks very useful as we are spending less time at the building and mostly working from home. I have previously managed to obtain a cabinet, for our servers, change the lock for a padlock based system and restrict the key holders to a few people. This means switching servers on, or off, is better controlled, but also makes it more difficult for the admins to reboot when they are at home. Can anyone point me towards a suitable 'power supply over IP' solution? Are there any drawbacks to using these? Stuart -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Networking standards
Given that you can now get 10Gb/s over cable and 10GB switches off the shelf reasonably affordable (at least affordable when compared to the same in fibre), I think that the only reason at the moment to use fibre is distance unless you have a very specific requirement. My guess is that by the time 10Gb/s speeds becomes common and needed, we will have a 100Gb/s over copper standard. Fibre is too brittle for day to day use in a workplace. Cheers, Marco. On 27/04/2021 10:00, Chris Bell via GLLUG wrote: Hello, Standard local networking rates have been faster than connections to the internet for many years, but fibre is slowly being laid around the UK so the internet is starting to catch up. I assume that sooner or later local networking will move on from Cat 5 or Cat 6 to all local fibre networks, prompted by whatever equipment suppliers choose as a standard. Is there any sign of this happening, and which standards are being considered? I have been viewing websites such as millsltd.com and farnell.com, both able to supply multiple varieties of fibre and connectors, but I am interested to know about any prospective standard, rather than which hardware might be available to adapt between different types. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] [OT] How to look stupid on the international stage.
I think the whole thing sums up Huawei 's attitude towards security, if one of their "top security engineers" thinks that the code was of an acceptable quality for production. Regardless of whether you subscribe to the whole China / backdoor stories, they have an appalling attitude to security. Oh well, at least nobody is suggesting that Huawei's gear is spreading the coronavirus Oops Marco On 13/05/2020 17:55, James Courtier-Dutton via GLLUG wrote: Hi, Would you hire this dev? https://www.zdnet.com/article/huawei-denies-involvement-in-buggy-linux-kernel-patch-proposal/ -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Internet Data Rate
...MUST NOT (rfc2119) I bet you know what BSI 0 is as well :-) -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Internet Data Rate
On 13/05/2020 13:20, John Winters via GLLUG wrote: P.S. I've found in the past that the best way to get one of the slot-in plates is to ply a friendly BT technician with tea and chocolate digestives (plain chocolate obviously). WARNING: Do not feed them after midnight. They turn into Virgin Engineers... -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Internet Data Rate
With so few people having / using POTS telephones these days, it is really hard to explain to people that the quality of the line affected the quality of the data. Most of the time when I turn up to fault-find a xDSL line, I start by plugging a £10 handset into the line, and then have to tell them it is a voice fault and we need to report it to the telephone company, not the broadband company. They usually just don't get it. My rule of thumb is that with HiFi, cheap digital is better than cheap analogue, and expensive analogue is better than expensive digital, but in data transmission systems it is the other way round. A cheap analogue fix is always better than even an expensive digital fix. :-) -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Internet Data Rate
I love it when people remind us that at the end of the day, all data is analogue once it hits a copper wire! Kudos to a proper bit of communications engineering, Chris :-) On 13/05/2020 11:01, Chris Bell via GLLUG wrote: Hello Frank, You could find that you get an improvement by using a replacement lower front panel VDSL filter for the incoming BT NTE5 termination box which will block the data from entering your internal telephone wiring. It will bypass the line filter in the standard box, which destroys the balance between the wires, and replace it with another after the data has been isolated, preventing your telephone wiring from acting as tuned aerial stubs. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Adding openvpn to an existing configuration
"...tunnel through firewalls..." Sorry :-) On 11/05/2020 11:05, Marco van Beek via GLLUG wrote: Hi, Openvpn should not be grabbing port 53 unless you are using a custom config for it. The default setup for openvpn is UDP 1194. Some people do use port 53 UDP for VPn because it allows you to tunnel through, but you have just seen what havoc that can bring. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Adding openvpn to an existing configuration
Hi, Openvpn should not be grabbing port 53 unless you are using a custom config for it. The default setup for openvpn is UDP 1194. Some people do use port 53 UDP for VPn because it allows you to tunnel through, but you have just seen what havoc that can bring. If you do need to run OpenVPN that way then I thionk you will need to run mulitple network interfaces and bind 53 in openvpn and dnsmasq to different ones. Regards, Marco On 11/05/2020 11:01, Chris Bell via GLLUG wrote: Hello, I have used several versions of debian, and have found that there are several networking and DNS resolver packages that could be used by default but generally do not take over if another is already running, so I end up checking all unless I know which is the only default. Debian version 10 "buster" appears to default to using systemd if it is configured, but many options could be automatically reset if re-booted. I have a computer running shorewall on debian 10 "buster" using dnsmasq for DHCP allocation to local networks, with access to recursive resolvers via local networks. Dnsmasq will not start if another package has grabbed port 53. I tried to add openvpn but then discovered that openvpn grabs port 53 on re- boot, and that blocks dnsmasq, so need to find a way to ensure that dnsmasq is started that will not be changed by any system update. Should the symlinks from /etc/systemd/system/ be used for this, with their BEFORE and AFTER settings? Thanks for any advice. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Perl programming project
On 08/04/2020 19:14, James Courtier-Dutton wrote: On Thu, 20 Feb 2020 at 10:57, Marco van Beek via GLLUG wrote: Basically we currently have an LDAP address book which is used by our desktop phones and our scanner. We also have started to use CardDAV as support is slowly extended into Thunderbird and Outlook (via a plug-in) but the VOIP phones and MFD do not understand CardDAV, so we need something to allow CardDAV to answer LDAP queries. After much unsuccessful searching (found one bit of bespoke code but the author never got back to me) I have figured out that OpenLDAP can use a Perl backend, and there is a Perl module that does CardDAV. We do not need a full two way conversation between the two, but as a project this does have the potential for a much bigger scope. It seems a bit confused to me. Do you have an LDAP server or a CardDAV server or both? I would have thought having a single server that can handle both query types is the way to go, because I expect the data model behind CardDAV and LDAP is different. One would probably need to design the data model from the start with both protocols in mind, to get this working well. Hi, Essentially it is a LDAP to CardDav / CardDAV to LDAP gateway, but rather than design something from the ground up, OpenLDAP has the ability to have custom backends, so my idea is simply to have a CardDAV backend to an OpenLDAP server. The CardDAV server could be anywhere. Yes, the data model is different, but our requirements are very simple, since all we are doing is serving telephone and mobile numbers up to desktop handsets and email addresses and fax numbers to multifunction printers. OpenLDAP supports both Bash and Perl for custom backends. All that is needed for full two way interactivity is 9 functions (https://linux.die.net/man/5/slapd-perl). I think we only need three of them for what we need, as we don't need two way traffic. Every LDAP / CardDAV project I have seen on the Internet fails because it tries to do too much, and be too many things to too many people. All I need is a standards compliant way of linking the two services. The moment you try to access the address book database you limit your choices. For example, Davical, which we use for CardDAV, using Postgresql, and OpenLDAP does support an SQL backend, but now both services really does need to be on the same server, and you cannot use a CardDAV collection on another system, and you cannot use another LDAP system on the primary server without worrying about bindings, so this really is a proxy system that could live on a VM and only do this small task. I could even see this running on a Raspberry Pi serving up an iCloud address book collection to a local MFP scanner in an office. So while I may not have explained myself, I was, in my defence, looking for a programmer to pay to do the work, not for a critique of my approach. I am very happy to explain my requirements and approach in more detail to someone who is interested in doing the work, but I did not want to fill the list with pages of details. Cheers, Marco -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Perl programming project
Hi, Resending this as I still haven't found anyone and circumstances have changed massively in the last 6 weeks. Cheers all. Marco On 20/02/2020 10:56, Marco van Beek wrote: Hi All, Wondering if there is anyone on the list who fancies a little Perl programming project? The resulting code would be open source (and happy for the author to put it up on SourceForge / etc) and it would appear to be a "much sort-for but never found" bit of code if my web searches are anything to go by. Long story short, we are trying to migrate from Samba3 with our own somewhat hacked version of OpenLDAP to Samba4 that has it's own version of LDAP that isn't really suitable for a couple of things we need to do with it. Basically we currently have an LDAP address book which is used by our desktop phones and our scanner. We also have started to use CardDAV as support is slowly extended into Thunderbird and Outlook (via a plug-in) but the VOIP phones and MFD do not understand CardDAV, so we need something to allow CardDAV to answer LDAP queries. After much unsuccessful searching (found one bit of bespoke code but the author never got back to me) I have figured out that OpenLDAP can use a Perl backend, and there is a Perl module that does CardDAV. We do not need a full two way conversation between the two, but as a project this does have the potential for a much bigger scope. Anyway, my Perl programming days are a while ago and right now whilst not exactly cash rich, I am time poor, so happy to throw some money in someone's direction if they think they can pull it off. I don't think it is more than a couple of days worth of work, but setting up a CardDAV system and an OpenLDAP system would be time consuming so we could fire up a VM with these already set up for someone to play with if that was needed. If anybody out there is interested let me know. Cheers, Marco -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
Thank you. AFAIK, due to the way Postgrey works, there is no list of “waiting” emails as if does not distinguish between one email retried 1000 times or 1000 emails sent once. So I really think the best you will be able to do is what has been done with postgreyreport with maybe the option to scan multiple log files. Regards Marco van Beek Supporting Role Ltd > On 3 Mar 2020, at 16:01, Henrik Morsing wrote: > > > Marco, > I apologise if I came across as rude, I just felt a massive debate had grown > from a simple quetion if a tool existed to mentioning some problem that I > didn't know what was. > >> On Tue, Mar 03, 2020 at 03:45:47PM +, Marco van Beek wrote: >> Those two do not contradict each other. > > No, but to me saying something doesn't know if something is waiting, then > that it stores the connection details with a timestamp, does. We will just > have to differ in that opinion. > > >> PostGrey simply stores an entry with a timestamp. It doesn't record that >> anything is waiting, just when the last SMTP connection was made. If >> someone sends an email to the same person from the same server every few >> days they are never greylisted, and for the same reason a second email >> from the same person on the same server sent 5:01 minutes later will >> sail through PostGrey checks, whereas the queued email sometimes doesn't >> arrive for hours. > > I know. > >> I think you are about to waste a lot of time and effort trying to read a >> database that won't tell you what you want to know, but it's not my time >> and not my problem. > > I don't really think I said what it was I wanted. I just find my-self > frequently being asked by my wife why a password reset mail (as an example), > hasn't arrived, and rather than constantly trawling through logs for her, I > could have a URL run a script that output the connections not yet white > listed for her to see. That would leave me out of the loop. > >> You may notice that nobody else has written back to say it works >> differently to what John and I have said, and we have been looking after >> email servers with PostGrey for over a decade, > > So have I, and I have never doubted how postgrey works. > > >> and I am the only person >> to tell you about the existing reporting tool, which isn't perfect but >> would give you somewhere to start to better understand the problem. > > And I still don't know what the problem I have mentioned is. All I am saying > is that that tool is an after-the-fact and statistics tool. >> I suggest you read the man page for postgreyreport: >> http://manpages.ubuntu.com/manpages/trusty/man1/postgreyreport.1.html >> [1] >> >> And then feel free to wind your neck in a bit and apologise. I >> appreciate English might not be your first language, but you have been >> very rude / arrogant towards me. I told you there was a tool, and by >> your answers, it looks like you didn't even bother to read up about it. >> > > I read the man page for that tool before I asked here. > I will see if I can write a tool for what I need. > > Thanks > Henrik Morsing -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
Those two do not contradict each other. PostGrey simply stores an entry with a timestamp. It doesn't record that anything is waiting, just when the last SMTP connection was made. If someone sends an email to the same person from the same server every few days they are never greylisted, and for the same reason a second email from the same person on the same server sent 5:01 minutes later will sail through PostGrey checks, whereas the queued email sometimes doesn't arrive for hours. I think you are about to waste a lot of time and effort trying to read a database that won't tell you what you want to know, but it's not my time and not my problem. You may notice that nobody else has written back to say it works differently to what John and I have said, and we have been looking after email servers with PostGrey for over a decade, and I am the only person to tell you about the existing reporting tool, which isn't perfect but would give you somewhere to start to better understand the problem. I suggest you read the man page for postgreyreport: http://manpages.ubuntu.com/manpages/trusty/man1/postgreyreport.1.html [1] And then feel free to wind your neck in a bit and apologise. I appreciate English might not be your first language, but you have been very rude / arrogant towards me. I told you there was a tool, and by your answers, it looks like you didn't even bother to read up about it. Regards, Marco On 2020-03-03 15:31, Henrik Morsing wrote: > On Tue, Mar 03, 2020 at 03:27:52PM +, Marco van Beek wrote: > >> How does it contradict everything I have said? > > - PostGrey doesn't care about what is waiting. > > - Nothing knows that it is in a 'waiting' state. > > Anyway, I am looking at writing something to read the database. All I really > asked if there was already a tool out there, and there isn't or at least > no-one has mentioned it yet. > > Thanks > Henrik Links: -- [1] http://manpages.ubuntu.com/manpages/bionic/man1/postgreyreport.1.html-- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
How does it contradict everything I have said? On 2020-03-03 15:16, Henrik Morsing wrote: > This contradicts everything you have said so far.-- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
I'm sorry, I really thing you are over-engineering the problem. In as simple a language that I can, this is what happens in postfix: * An SMTP connecting is made. Postfix accepts the initial HELO, Mail >From and Rcpt To. * Postfix supplies this information to PostGrey * Postgrey does a lookup of the sending server (I think it does it by host name from the EHLO but it might be by IP address), and the from address. * If it finds no entries, it adds one with the current time stamp, and rejects the SMTP connection with a "temporarily unavailable" message. * If it finds an entry, it checks the stored time stamp against the current time. If it is over the delay setting, it allows it and updates the timestamp. * Somewhere along the way there is a cleanup task that removes old entries. That's it. It is that simple. That is why PostGray can be a 'bit stupid' with some mail systems that use multiple relays on resends. Regards, Marco On 2020-03-03 14:31, Henrik Morsing wrote: > On Tue, Mar 03, 2020 at 02:28:55PM +, Marco van Beek wrote: > >> When it connects again it just does the maths and if it is more than 300 >> seconds it lets it through. > > Since what? If it's stateless, what will it compare the 300 seconds to? > > It's just impossible, but nevermind, I will figure it out. > > Thanks > Henrik-- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
Sorry, you are overestimating PostGrey’s ‘inteligence’.PostGrey doesn’t care about what is waiting. It just tells the connecting server to go away and come back later. When it connects again it just does the maths and if it is more than 300 seconds it lets it through. It then updates the database with the timestamp. Then at the other end if the timestamp is older than 30 days it gets pruned out of the database. Regards Marco van Beek Supporting Role Ltd > On 3 Mar 2020, at 12:24, Henrik Morsing via GLLUG > wrote: > >> On Tue, Mar 03, 2020 at 11:56:10AM +, Marco van Beek wrote: >> Hi, >> >> Nothing knows that it is in a ‘waiting’ state. All PostGrey does is record >> the combination of the IP address and the email address and the time of >> first contact. >> >> It is up to the sending server to retry, at which post postgrey checks the >> database entry and as long as it is past to 300 second delay, raises no >> objections and lets it through. >> > > I'm sorry but you are contradicting yourself. > > It must know that something is waiting, how else would it know if it has > passed the 300 seconds? > > And you go on to say it checks the database entry... I will try again to make > sense of the database files, will possibly need to read through the code for > help. > > Thanks > Henrik Morsing > > -- > GLLUG mailing list > GLLUG@mailman.lug.org.uk > https://mailman.lug.org.uk/mailman/listinfo/gllug -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
I think it is the only tool that can tell you if a delayed mail was subsequently allowed. The database only holds a list of IP addresses and when they were added. I am pretty sure it doesn’t log any message traffic stats. Regards Marco van Beek Supporting Role Ltd > On 3 Mar 2020, at 08:05, Henrik Morsing via GLLUG > wrote: > >> On Tue, Mar 03, 2020 at 08:03:35AM +0000, Marco van Beek via GLLUG wrote: >> Think it might be called postgreyreport >> >> There is some info about it on this page: >> >> https://wiki.centos.org/HowTos/postgrey >> > > Hi and thanks, but Postgreyreport just looks at past delayed mail in the log > file. It's purely a statistics tool. Unless someone can prove me wrong? > > Thanks > Henrik Morsing > > -- > GLLUG mailing list > GLLUG@mailman.lug.org.uk > https://mailman.lug.org.uk/mailman/listinfo/gllug -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
Think it might be called postgreyreport There is some info about it on this page: https://wiki.centos.org/HowTos/postgrey Regards Marco van Beek Supporting Role Ltd > On 3 Mar 2020, at 07:59, Marco van Beek via GLLUG > wrote: > > There is a reporting tool that goes through your mail logs and finds the > entries that have been delayed by postgrey and haven’t sucesssfully > resubmitted. It isn’t 100% as it doesn’t look in rotated logs, and I can’t > remember what it is called, but there was one a few years ago. > > Marco van Beek > Supporting Role Ltd > >> On 3 Mar 2020, at 07:35, Henrik Morsing via GLLUG >> wrote: >> >> >> Hi, >> >> I have been trying to find out if there is a way of seeing what currently >> has a wait against it in Postgrey but have been un-successful. >> Does anyone know of a way to do this? I have dumped the Berkeley DB files >> but the long strings in there means nothing so short of starting to look at >> the Portgrey code to see what it actually writes to them... >> >> Thanks >> Henrik Morsing >> >> -- >> GLLUG mailing list >> GLLUG@mailman.lug.org.uk >> https://mailman.lug.org.uk/mailman/listinfo/gllug > > > -- > GLLUG mailing list > GLLUG@mailman.lug.org.uk > https://mailman.lug.org.uk/mailman/listinfo/gllug -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Postgrey holding list
There is a reporting tool that goes through your mail logs and finds the entries that have been delayed by postgrey and haven’t sucesssfully resubmitted. It isn’t 100% as it doesn’t look in rotated logs, and I can’t remember what it is called, but there was one a few years ago. Marco van Beek Supporting Role Ltd > On 3 Mar 2020, at 07:35, Henrik Morsing via GLLUG > wrote: > > > Hi, > > I have been trying to find out if there is a way of seeing what currently has > a wait against it in Postgrey but have been un-successful. > Does anyone know of a way to do this? I have dumped the Berkeley DB files but > the long strings in there means nothing so short of starting to look at the > Portgrey code to see what it actually writes to them... > > Thanks > Henrik Morsing > > -- > GLLUG mailing list > GLLUG@mailman.lug.org.uk > https://mailman.lug.org.uk/mailman/listinfo/gllug -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Console screen size
:-) Thanks anyway, think it's sorted! Henrik -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Console screen size
HI, If you are using HDMI you might be falling foul of over-scanning: https://www.howtogeek.com/252193/hdtv-overscan-what-it-is-and-why-you-should-probably-turn-it-off/ If you are lucky there is a setting on the TV to turn it off. Regards, Marco On 24/11/2019 12:47, Henrik Morsing via GLLUG wrote: Hi, My Debian server console is hooked up to a TV. This used to work fine, but Debian updates over time have made the console visible area shrink more and more on the screen. I've found out how to set the resolution and font in GRUB and other places, but neither of these change the actual screen size. What makes the console size fit the screen it is attached to? This doesn't ever seem to be a problem on computer monitors, so how is a TV different? And is it a PC/BIOS(UEFI) thing maybe, rather than a Linux problem? Thanks Henrik Morsing -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Ubuntu 19.10 release Get Together
I think the first version I installed was 5:10, and I had to set up a 12 x 400GB array as a block device (dev/sbd rather than /dev/sdb1) as although I could set up a partition table that recognised the 4TB+ array, the 32bit check tool during start-up "fixed" it down to 2TB. Happy days :-) On 16/10/2019 15:50, Matthew Smith via GLLUG wrote: Whose 15th release? Ubuntu has been round the alphabet and more; it must be about the 31st release. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
Re: [GLLUG] Server in London
Hi, On some VM offerings you get a remote KVM, which would allow you to get "physical" console access, and then you could encrypt the whole OS and use the KVM to enter the key on reboot. That should prevent anyone in the data centre from using the disk image without your key. Regards, Marco On 11/10/2019 09:19, Andy Smith via GLLUG wrote: You hint at not wanting to go the virtual server route because of concern for the safety of your data. I think that looking at it this way is a bit of a mistake; the correct response to concern over your data is to have good backups of your data. -- GLLUG mailing list GLLUG@mailman.lug.org.uk https://mailman.lug.org.uk/mailman/listinfo/gllug
