- Roundtable - muug.ca

Old MUUG server up for grabs! ($$$)
by Adam Thompson 16 Feb '22

16 Feb '22

We’re getting rid of the old server! It’s up for auction, to MUUG members in good standing only. We’re taking bids for the rest of the month by email. Emailed bids must be received by me no later than Monday 2022-Feb-28 23:59:59 to be considered eligible. We’re doing this as a “blind auction<https://en.wikipedia.org/wiki/First-price_sealed-bid_auction>”, where everyone submits their bid to me (Adam Thompson), and at the end of the bidding period, I’ll contact the highest bidder. If they’re unable to follow through for any reason, it goes to the second-highest bidder, and so on. We cannot issue a receipt for tax purposes. The MUUG board (excluding board members who entered bids themselves) shall be the only, and final, avenue of appeal for anything related to this auction. Since we already know some of the board is planning to bid, and I am not, send your bids to me directly: athompso(a)muug.ca<mailto:athompso@muug.ca> (or my usual address, they both wind up in the same place), and not to board@. Please provide name, email, phone#, and dollar amount. If you don’t receive a confirmation from me within a few days, post to roundtable letting me know something’s wrong. And/or try a different email provider. The server is about 6yrs old, it’s a 1U rack-mount server from ASUS with 12 x 4TB NAS HDDs, 2 x 2.5” SSDs, a Xeon (E3 v3) CPU, 32GB of RAM, 2 x 1G & 2 x 10G(SFP+) ethernet ports. To reiterate that point, we’re selling it with 48TB of mostly 5400rpm SATA “NAS”-type hard drives (and two SSDs) included. All the drives will be ATA Security Erased before you get the unit. (This could make an awesome 40TB FreeNAS unit for storing backups!) The winner can come pick up the server from my place in north Winnipeg, where it’s currently stored. If you can’t come pick it up, there are ways to get it to you but you might be on the hook for delivery charges (modest, if you’re in Winnipeg). You’ll be expected to get the server out of here by March 7th (one week after bidding closes), one way or another. -Adam (see below for lots more words) Detailed server specs: * ASUS RS300-H8-PS12<https://www.asus.com/ca-en/Commercial-Servers-Workstations/RS300H8PS12/> * 1U rack server * integrated ASUS P9D-MH/SAS/10G<https://www.asus.com/ca-en/Commercial-Servers-Workstations/P9DMHSAS10GDUAL/> microATX motherboard * Xeon E3-1230v3 (any E3-1200v3 processor is supported) * 32GB RAM (4 x 8GB DDR3 Unbuffered ECC) * 1 low-profile PCIe slot is usable in this chassis using a riser (included) * 4 x SATA 6GB/s & 2 x SATA 4GB/s on motherboard, pre-wired to drive bays * 8 x SAS 6GB/s (supports SATA III) on embedded LSI2308<https://docs.broadcom.com/doc/12351997> controller, pre-wired to drive bays * 2 x Intel I210AT 1gbps ethernet * 2 x Broadcom BCM57840 NetXtreme II 10gbps ethernet (see notes) * Built-in ASMB7-iKVM<https://www.asus.com/ca-en/Commercial-Servers-Workstations/ASMB7IKVM/> remote server management with dedicated 100M ethernet port * integrated 400W 80PLUS Gold power supply – looks proprietary? * 4 “warm-swap” carriers holding 3 x SATA HDDs each (see notes) * Proprietary mounting rails are included * 12 x 4TB “NAS”-type HDDs. Mixture of WD RED, Seagate IronWolf, and Hitachi something-or-other. * 2 x 250GB SSDs. Intel 545S & Samsung 850 EVO NOTES * The HDDs range in age from original to recently replaced. * The server must be powered off to replace drives, despite the fact it looks like hot-swap at first glance. * Linux bnx2x kernel driver bugs in some versions of some distros affect the ability to use the onboard Broadcom NetXtreme II 10-gigabit NICs. They’re fine in Debian 9, but unusable in Debian 10. Believed to work fine under FreeBSD (FreeNAS) and other non-Linux kernels… VMware is anyone’s guess. * 1U rack-mount servers have fans running between 10krpm and 24krpm. It will be very loud. * It can only be operated horizontally (e.g. in a rack). It’s also fairly heavy because of the 12x 4TB drives. * The onboard video is, as is usual for servers, unsuitable for desktop use. * Original user manuals are provided. * No warranty. There might be a bit of warranty on one or two drives, but don’t count on it. Otherwise… It could die the moment you plug it in. It could eat your family for breakfast while you’re at work. It could start WWIII. MUUG guarantees nothing more than if we take your money, you’ll get a very large quantity of mostly-metallic molecules in the shape of a server. Having said all that, it ran continuously for 6 years, the only things that died were the various drives, and it was still working perfectly when I removed from the rack at Les.net earlier this month. Pricing/value considerations: (all prices taken from Newegg.ca today) * E3-1230v3 goes for $300 today. A similar modern server CPU (E-2124) runs $270. * 32GB of Unbuffered DDR3 ECC goes for $190 today. 32GB of DDR4 ECC runs $308. * 4TB NAS HDDs go for $100 today. That’s normal pricing, no age or scarcity effects. * 1U “barebone” servers of a similar class/category run around $440 today. (That one doesn’t have 12 x 3.5” bays, but… meh, close enough.) So to rebuild this server with brand-new parts, you’d be looking at almost $2200. THIS server, however, is used and there’s no warranty, so… bid based on what it’s worth to you!

1 0

gOOgle/gmail prying eyes
by eh＠eduardhiebert.com 13 Feb '22

13 Feb '22

Hi, Pertaining reasonable privacy concerns one key question, but first the qualifiers. Any and all email crossing gOOgles hands whether their user or NOT gets copied and data mined. If a non-gmail address sends one email to multiple contacts and one of them is on gmail or to any of gOOgle's cloaked and hidden email service account provider such as for the CBC, gOOgle has access to it. My question is, if an email is sent to multiple parties and even if one of these is gmail, but should those who are on BCC (the non gmail ones) still somehow be visible to gmail? Thanks, Eduard

4 5

Reminder: MUUG Online Meeting, Tonight, Feb 8, 7:30pm -- Tactical RMM
by Gilbert E. Detillieux 08 Feb '22

08 Feb '22

A reminder that the MUUG online meeting will be on BBB this evening... The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting online, on Tuesday, February 8th, at 7:30pm: Tactical RMM This month's presentation is on Tactical RMM, a powerful, self- hosted tool for managing large amounts of Windows computers. Chris Audet will demonstrate some common use cases for TRMM such as patch management, client system health checks, and remoting into client computers to provide support. This will once again be an online meeting. Stay tuned to our muug.ca home page for the official URL, which will be made available about a half hour before the meeting starts. (Reload the page if you don't see the link, or if there are issues with connecting.) The group holds its meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. For more information about MUUG, and its monthly meetings, check out their web server: https://muug.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board, or linking to it on social media: https://muug.ca/meetings/MUUGmeeting.pdf -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.ca> Manitoba UNIX User Group Web: http://muug.ca/

1 0

Re: [RndTbl] Holy fanless computing, batman... (eh@eduardhiebert.com)
by Brock Wolfe 06 Feb '22

06 Feb '22

One Canadian source with prices for the MB's mentioned http://www.atic.ca/index.php?page=newsearch&searchterm=M11SDV-8CT-LN4F&x=51… http://www.atic.ca/index.php?page=newsearch&searchterm=A2SDi-H-TF&x=34&y=5 Brock

3 2

Holy fanless computing, batman...
by Adam Thompson 04 Feb '22

04 Feb '22

SuperMicro’s A2SDi-H-TF : * 2.2GHz Denverton (Atom C3758) CPU architecture, 8 cores w/16MB each but not superscalar, no Turbo, and no HT. Still plenty fast enough for most applications. * Up to 256GB of ECC RAM. * Dual 10G onboard. * 13 x SATA ports (including 1xSuperDOM), 8 of them delivered via 2x Mini-SAS HD ports * 1 x PCI-E x4 * 1 x M.2 * 1 x internal USB 3.1 (type A) port * IPMI and remote mgmt. subsystem onboard And although there are 4 fan headers, this is a Mini-ITX (!) board that runs a cool 25W (i.e. fanless!!!). There’s an entire series of them this year from SuperMicro, all having slightly different configurations. I know I’m getting old, but this is as incredible to me as my current equipment would have been to 10- or 20-years-ago me. -Adam

3 3

Slackware 15 is released
by Alberto Abrao 03 Feb '22

03 Feb '22

A few days after the newsletter, here it is: http://www.slackware.com -- Sent from a phone.

5 4

MUUG Online Meeting, Tuesday, Feb 8, 7:30pm -- Tactical RMM
by Gilbert E. Detillieux 01 Feb '22

01 Feb '22

The Manitoba UNIX User Group (MUUG) will be holding its next monthly meeting online, on Tuesday, February 8th, at 7:30pm: Tactical RMM This month's presentation is on Tactical RMM, a powerful, self- hosted tool for managing large amounts of Windows computers. Chris Audet will demonstrate some common use cases for TRMM such as patch management, client system health checks, and remoting into client computers to provide support. This will once again be an online meeting. Stay tuned to our muug.ca home page for the official URL, which will be made available about a half hour before the meeting starts. (Reload the page if you don't see the link, or if there are issues with connecting.) The group holds its meetings at 7:30pm on the second Tuesday of every month from September to June. (There are no meetings in July and August.) Meetings are open to the general public; you don't have to be a MUUG member to attend. For more information about MUUG, and its monthly meetings, check out their web server: https://muug.ca/ Help us promote this month's meeting, by putting this poster up on your workplace bulletin board or other suitable public message board, or linking to it on social media: https://muug.ca/meetings/MUUGmeeting.pdf -- Gilbert E. Detillieux E-mail: <gedetil(a)muug.ca> Manitoba UNIX User Group Web: http://muug.ca/

1 0

PHP undefined vars / array indices
by Trevor Cordes 24 Jan '22

24 Jan '22

Any PHP coders out there? So PHP really did it in 8.0: They really made accessing undefined vars *and* array indices a full warning rather than a notice. I had written in past newsletters that I hoped this didn't mean what it sounded like it meant. But it does. They really did it. https://wiki.php.net/rfc/engine_warnings I finally had to face the music with the upgraded MUUG server which now uses PHP8. It was coming for me in Fedora 25 anyhow (maybe 4 more months to postpone that change). The MUUG server is about 80% code that Allan Pollard wrote (thanks Allan!) and 20% my own code. Neither wrote according to PHP8's magic new requirements. Anyone here who does PHP and hasn't treated it as a typed / declared language, because it is not one, is in for a great deal of pain when they are forced to upgrade to PHP 8. I'm not sure I've ever come across existing PHP code where the dev treated it as a language where you must pre-declare everything. Of course, such people must exist, as exhibited by the voting record for this PHP RFC. Perhaps they are people who only recently took up PHP and/or are coming from stricter languages. And that is my main beef: if you want a strict language, use a strict language. Why take a loose language, which has always been loose and is loose by design, and suddenly make a major change that is going to spew out errors all over everyone's screen (if display_errors is on) for 90% of all legacy code? If I want strict variable declaration, I'll use one of the zillion languages that force you, and even do nice compile-time checks for you. And you just know that while, at the moment, this change is limited to making it a warning, the tyrants are itching to make this a full explosion error. You can see it in the voting ("Change undefined variable severity to?": vote 36 to 28). Luckily for us PHP requires a 2/3 majority to pass an RFC. To "fix" these errors in code, you can in most cases use a lot of tricks, like massive use of ?? everywhere. But that makes the code look really ugly and I start to question why? And if you use list() to capture results of a function which can return variable type of variable length arrays, you're really in trouble as there's no current syntax to combine ?? or isset() with that. Sure, you can go in and turn your PHP into C by pre-declaring every variable, if you can spot them all in complex functions or global scope code. But that only helps you with the "undefined variables" thing, not the "undefined array index" thing. The latter is far more insidious because your index can be a variable itself! So for that case you must always use isset() or ?? or some other trick. I could go into more examples of what I had to do to the MUUG code if anyone is interested. So what can you do in the real world? The first thing you do is turn off display_errors, which is probably off on production boxes anyhow (but wasn't on "hobby" boxes like MUUG, but it is now). Then make sure those warnings are being logged. Then sit back and let people use your site and wait for the MBs of log lines saying undefined this and that. Then you have a choice: a) ignore it all and set your logrotate to a short period of time so you don't fill your log disks; or b) fix every error that shows up. I did (b) on MUUG and it's not fun, and that's just a small code base. In either case you must pray the PHP tyrants don't soon vote this into a runtime exception error, as when you retrofit your old code you're almost never going to find every instance of this. Compare this situation with perl strict. Perl introduced "strict" mode with "use strict" a long time ago. That makes you my() every variable and its dog or you get a full blown error. But I'm pretty sure it doesn't affect array indices. In any event, if you don't agree with the perl devs, you just write "no strict" (or just disable this specific strict). No tyrrany. Freedom and choice. Perl, like PHP has never been strictly typed or declared. Perl will never force you to use strict. Never. So why is PHP? PHP could have made it a configurable option. It would be really easy. But they didn't. I have some projects with over 100k lines of PHP code. The simple fact that "fixing" this will make my code look extremely ugly, harder to read, less maintainable, and probably more prone to bugs is all the reason I need to decide that I will never "fix" my code. Not to mention it will be probably 20k lines of code that need to be "fixed", and it's a pointless pursuit because in the end I'll never find them all. (grep -P '\[' ... ya right.) So it will be log & ignore, or not log at all (though I still will need to see legit warnings somehow); or git clone php and change 2 lines of code and maintain my own version forever. In fact, it may be time to do a fork of PHP: sane-php or something. Lastly, I'm willing to debate the philosophical points, especially using the RFC's wording as a basis; however, I'm not sure anyone is interested in taking the other side (please, hardcore PHP programmers only). I'll leave you with the arrogant wording from the RFC: In most cases, accessing an undefined variable is a severe programming error. The current low classification is a legacy from the Dark Ages of PHP, where features like register_globals made conditionally defined variables more typical, and code quality standards were lower. [...] However, throwing an exception may complicate the upgrading of legacy code that currently suppresses the generation of notices wholesale, as the issue can no longer be ignored. Some people have even suggested that the use of undefined variables is a legitimate coding style choice. "Legacy", "Dark Ages" indeed. Nice framing. "Legitimate coding style choice." How gracious.

7 19

Re: [RndTbl] Electronic filling in Manitoba Public Insurance Forms: Billing Travel etc medical expenses
by eh＠eduardhiebert.com 21 Jan '22

21 Jan '22

I use a different email program for these MUUG exchanges and for whatever reason the bells and whistles said it was sending to the group, but after the fact appears it was only sent to Adam. So my apologies I hereby correct my error. Eduard -------- Original Message -------- Subject: Re: [RndTbl] Electronic filling in Manitoba Public Insurance Forms: Billing Travel etc medical expenses Date: 2022-01-21 04:52 From: eh(a)eduardhiebert.com To: Adam Thompson <athompso(a)athompso.net> Reply-To: roundtable(a)muug.ca In short, Adam thanks for sharing of your insight and experience. As a result of your timeliness, as you can see, thanks to yours I will now have an early start. Simultaneously I will add I am literally on an unrelated task focusing on toolmaking, both its functional capacities to do more with less effort. But in short, in areas of my own life, like you I too have more than enough history of been there done that working my way into dead ends. But of course not always Hope can spring eternal and through the collective of MUUG I am now a more comfortable user of safe email and with you having so much more tech background in the area now under discussion, as can be seen from my request, did not want to leave a reasonable stone unturned. But many thanks for turning this stone for me without me having to repeat history. Many thanks and this in such a timely way! Truly Happy New Year to one and all as we do individually and collectively what reasonably can be done, including so to say chewing our own food. Thanks! Eduard On 2022-01-20 20:28, Adam Thompson wrote: > [Replying off-list, since it's not even remotely UNIX-related.] > > Been there, done that. You may as well start the manual filling, > typing, or writing as soon as you get up. Sorry :-( > I'm *very* familiar with those MS Word "forms" that aren't really > forms in any programmatic sense. You could write an app in VBA to do > it, but that would take a LOT longer than just filling them out > yourself. (I should know, I tried.) > MPI takes handwritten forms as well as typed or filled out in MS Word. > (Not everyone has a computer, or Word, or a working printer, or...) > That may or may not be easier for you - depends on how fast you type > and mouse versus how fast you can write, I guess? > -Adam > > > -----Original Message----- > From: Roundtable <roundtable-bounces(a)muug.ca> On Behalf Of > eh(a)eduardhiebert.com > Sent: Thursday, January 20, 2022 9:40 PM > To: roundtable(a)muug.ca > Subject: [RndTbl] Electronic filling in Manitoba Public Insurance > Forms: Billing Travel etc medical expenses > > With all that knowledge among members, if readily and easily possible > without a significant learning curve, can anyone direct me to a program > or how to, to easily transfer data I already have in a text file to the > attached forms? > > MPI has refused my multi pages of billings unless literally on their > forms as attached. > > I plan on doing it tomorrow and will start the manual method as my last > resort by noon. > > Thanks, > > Eduard

1 0

Electronic filling in Manitoba Public Insurance Forms: Billing Travel etc medical expenses
by eh＠eduardhiebert.com 20 Jan '22

20 Jan '22

With all that knowledge among members, if readily and easily possible without a significant learning curve, can anyone direct me to a program or how to, to easily transfer data I already have in a text file to the attached forms? MPI has refused my multi pages of billings unless literally on their forms as attached. I plan on doing it tomorrow and will start the manual method as my last resort by noon. Thanks, Eduard

1 0