/proc and /sys filesystems ...
Some bits from yesterday's BALUG meeting.
There was some response and more information that also
came up on the SF-LUG list:
http://linuxmafia.com/pipermail/sf-lug/2018q3/013428.htmlhttp://linuxmafia.com/pipermail/sf-lug/2018q3/013430.html
And (mostly) from the BALUG meeting ...
mostly lots of folks various favorite bits and other things
/proc and /sys discussed:
Is it virtual? Don't have dmidecode(8) or similar?
$ cat /sys/devices/virtual/dmi/id/product_name
Can even work that into use in a script, e.g.
#!/bin/sh
#... case ...
'Bochs'|'HVM domU'|'VMware'*|'VirtualBox')
The above would respectively match virtual machines of (at least some
of) the varieties:
QEMU/KVM
Xen
VMware
VirtualBox
I have /dev/sda and /dev/sdb as internal drives,
I insert two USB flash drives at about the same time, giving me now also
/dev/sdc and /dev/sdd.
One's about 2 GB in size, and the other about 32 GB.
Which is which?
$ grep . /sys/block/sd[cd]/size
/sys/block/sdc/size:4089856
/sys/block/sdd/size:62530624
$
What are their exact sizes?
... Oh, we also have that above - in the number of 512 byte blocks
I'm done with /dev/sdc, I pull it out.
$ ls -d /dev/sd[c-z]
/dev/sdd
$
At present I'm not using /dev/sdd (nothing having it open or mounted
from it, etc.), I'd really like it as /dev/sdc rather than sdb, but I
don't feel like taking my fingers away from the keyboard or adding the
wear and tear to the USB connectors.
This removes it:
# echo 1 > /sys/block/sdd/device/delete
#
$ ls -d /dev/sd[c-z] 2>>/dev/null
$
This scans for drives:
# (>>/dev/null 2>&1 ls -d /sys/class/scsi_host/host*/scan && for tmp
in /sys/class/scsi_host/host*/scan; do echo '- - -' > "$tmp"; done)
#
$ ls -d /dev/sd[c-z] && grep . /sys/block/sd[c-z]/size
/dev/sdc
62530624
$
I plug in an additional USB flash device:
$ ls -d /dev/sd[c-z]
/dev/sdc
/dev/sdd
$
What if their sizes weren't all that different, but I wanted to know
which was which?
ls -d /sys/block/sd[cd]/device/*
$ (cd /sys/block && grep . sd[c-z]/device/vendor sd[c-z]/device/model) | sort
sdc/device/model:Cruzer Blade
sdc/device/vendor:SanDisk
sdd/device/model:USB 2.0
sdd/device/vendor:
$
/proc/[0-9]* - PIDs (and that much will match not only Linux, but also
as far as I'm aware, any other *nix flavor (notably Unix) that also has
a mounted /proc filesystem)
/proc/[!0-9]* - lots of other interesting/useful non-PID stuff
/proc/PID/fd/* - open file descriptors for the PID - these are
represented as symbolic links to the physical pathname of the file (at
least for filesystem files), if the file is unlinked, it will have
" (deleted)" on the end; 0 is stdin, 1 stdout, 2 stderr.
I have some PID of some something I'm unfamiliar with - maybe it's
undocumented ... maybe I want to know if it's writing some log
information ... may be quite useful to look at /proc/PID/fd/[12] - it
may possibly be there, ... or possibly some other file(s) it has open
(especially if it's not using syslog).
File unlinked, but need to save/retrieve the data (it's still
open by the PID)?:
$ cat /proc/PID/fd/file_descriptor_number > file_to_save_data_in
/proc/PID/environ - what's in the environment (each ASCII null terminated)
/proc/PID/exe - the binary executable
/proc/PID/cwd - Current Working Directory
When exactly did that process start?
$ stat -c '%z' /proc/PID
Grew (or shrunk) the size of a device (e.g. LUN), want the kernel to
know about it? E.g.:
# echo 1 > /sys/block/sdb/device/rescan
/proc/cpuinfo - lots of useful information about the CPU(s), flags may
be of particular note (e.g. is your CPU 64 or 32 bit - how old of which
kernel/distribution can it still run ... or run without additional
kernel parameters to enable use of some CPU feature present on the CPU
but which the CPU doesn't "advertise"). What CPU hardware bugs are
worked around (or partially so) via kernel software? How many cores? ...
/proc/cmdline - what arguments were given to the kernel at boot?
/proc/version - kernel version
/proc/sys - a precursor to the /sys filesystem, also much kernel
information and tunable parameters there - see also sysctl(8)
/proc/mounts - kernel's idea of what's mounted and how - this is
especially useful when /etc/mtab doesn't fully or well provide that
information. Note that for many distributions, /etc/mtab may be a
symbolic link to /proc/mounts.
Especially the /proc filesystem, and also /sys filesystem are relatively
essential in Linux. E.g. without /proc filesystem mounted, many common
utilities, e.g. ps(1), won't work.
Backup /proc and /sys filesystems? You generally would *not* want to do
that. They're pseudo (/"virtual") filesystems, most notably reflecting
lots of state information of the current running system. But they're
ephemeral/volatile - prior contents don't really matter at all after a
reboot.
If one cares about competitiveness among ISPs, choice,
and generally having quality options, this is one to pay attention to
and take action on.
If you prefer negligible choices, and ISP services to only be provided by
the large monopoly/oligopoly players, and generally with poor quality,
higher prices, and most or all other players squeezed out, then feel
free to completely and totally ignore this.
----- Forwarded message from mdurkin(a)rawbw.com -----
Date: Wed, 29 Aug 2018 00:03:31 -0700 (PDT)
From: "Mike Durkin" <mdurkin(a)rawbw.com>
Subject: Raw Bandwidth and other competitive Internet access
providers need your help at the FCC today!
To: michael.paoli(a)cal.berkeley.edu
Dear Raw Bandwidth Customer or former customer:
It's a rarity that I email all of our customers (and some former
customers), but we are at a critical moment for competitive Internet
access, so I hope you'll excuse the intrusion.
In early May, USTelecom, a lobbying group headed by large incumbent
monopoly phone companies AT&T and Verizon, filed a petition at the Federal
Communications Commission (FCC) to "forbear", that is to no longer enforce,
provisions of the Telecommunications Act of 1996 which are critical to many
independent Internet access providers like Raw Bandwidth reaching its
customers with service. The Telecom Act rewrite in 1996 requires the
incumbent phone companies to unbundle and rent discrete network elements to
competitors at regulated rates--especially elements such as the pairs
of copper wire running through the streets that they have a monopoly
over and have no competition for--so that competitive providers
can also use the elements in their services. I am writing to ask
you to take action by filing comments at the FCC in support of independent
Internet access providers (we'll help you do it), to tell the FCC what
it means to you to have choice in your Internet provider, and to urge
them to deny the petition. (The petition would also affect competition
for voice phone service.)
Here is a good article that summarizes a lot of what's at stake:
https://www.engadget.com/2018/07/11/small-internet-providers-face-a-fight-f…
(Note this article says the FCC would vote on the petition on August
6th, but that's incorrect; August 6th was a filing deadline for
opening comments, and September 5th is the next deadline for reply
comments. The FCC won't vote on the petition until late this year
at the earliest, but informal comments need to be filed now.)
Explaining what's at stake takes a lot of words, so I've made a web
page that explains what the petition is all about, and also contains
links to help you easily file comments at the FCC (all done online) to
support competitive Internet access. Please take a look at the web
page and instructions here
http://www.rawbandwidth.com/clec/forbearancepetition.html
The short version is that if the FCC grants the petition as requested,
independent DSL and Ethernet over Copper providers like Raw Bandwidth
will see cost increases (due to removal of rate regulation from
monopoly network elements only available from incumbent monopoly providers
like AT&T--a single provider of the element to any particular location) that
will result in an increase in retail rates, and some coverage areas are
likely to be lost over time. The petition should not be granted under
the standards it is supposed to be judged on, and providers like Raw
Bandwidth are filing detailed rebuttals to the petition, but the current
FCC and political climate is one for gutting regulations, so despite that
it should be denied, there is a significant risk that it may be granted.
Please take the time to weigh in with the FCC and tell them how important
it is to you to have competitive choices at competitive prices, and urge
them to deny the petition. Your comments submitted to the FCC by
September 5th are important!
I don't intend to send any followups to this email by email so as
not to be any more intrusive. Instead I will post updates to the status
of the petition at the same web page
http://www.rawbandwidth.com/clec/forbearancepetition.html
including links to the FCC's decision once available and an explanation of
how the result affects our business and service to customers.
As always, thanks for your business and support!
Mike Durkin
Raw Bandwidth
mdurkin(a)rawbw.com
----- End forwarded message -----
(This happened automatically because the address has not been
deliverable for a long time.)
In case people had not heard, longtime Bay Area Linux activist Darlene
Wallach died of cancer on July 12, 2017.
https://www.indiegogo.com/projects/help-fund-darlene-wallach-s-cancer-cure-…
----- Forwarded message from mailman-bounces(a)lists.balug.org -----
Date: Fri, 10 Aug 2018 09:00:02 -0700
From: mailman-bounces(a)lists.balug.org
To: balug-talk-owner(a)lists.balug.org
Subject: BALUG-Talk unsubscribe notification
freepalestin(a)dslextreme.com has been removed from BALUG-Talk.
----- End forwarded message -----
Don't know about about this, but in case someone might
be interested and may find it of use/value:
----- Forwarded message from gary.gwaltney(a)ktcs.biz -----
Date: Tue, 17 Jul 2018 10:10:24 +0000
From: "Gary Gwaltney" <gary.gwaltney(a)ktcs.biz>
Subject: PLEASE PASS TO MEMBERS
To: "balug-webmaster(a)balug.org" <balug-webmaster(a)balug.org>
Please share with your members:
RHCSA Rapid Track
course<https://www.knowledgetransferinc.com/computer-training/courses/kt-rh199/rhc…> ? Virtual Class July 23-26<x-apple-data-detectors://3> Start time will 8:30pm
EDT<x-apple-data-detectors://4>
**Instructor has 32 years training Unix, Linux...our training manual
is by fats one the best resources for the students who are seeking
both the Certification and obtaining new skills. We have over 21 yrs
in providing the highest quality training!! This last minute offer is
an incredible opportunity for your members. Limited seat available!
Gary.gwaltney(a)ktcs.biz<mailto:Gary.gwaltney@ktcs.biz>
The course reviews the tasks covered in Red Hat® System Administration
I (RH124) and Red Hat® System Administration II (RH134) at an
accelerated pace. On completion of course materials, you should be
prepared to take the Red Hat Certified System Administrator (RHCSA)
exam.
Red Hat Price: $3,700
Member Price: $1,995 includes one exam voucher (value of $400) or
$2,495 includes two exam vouchers ($ 800 value)
Sent from my iPhone
----- End forwarded message -----
> Can we go over the security topic from a few meetings ago?
Sure, we can (also) go over that at today's BALUG meeting -
presuming folk(s) are interested.
I think I only made it about 1/3 or of the way through my security
materials on that earlier - that was the meeting from about
two months ago - 2017-05-15.
I do also have "slides" from that ... I should get those up fairly
soon too.
> From: "Kim Davalos" <kdavalos(a)sonic.net>
> Subject: Re: [BALUG-Announce] BALUG: meeting TOMORROW!: Tu
> 2018-07-17; & other BALUG News
> Date: Tue, 17 Jul 2018 07:31:53 -0700
> Can we go over the security topic from a few meetings ago? I don't
> think we had the opportunity to cover it at the time. Just a thought.
>
> ~Kim
>
> On 07/16/2018 01:05 PM, Michael Paoli wrote:
>> BALUG: meeting TOMORROW!: Tu 2018-07-17; & other BALUG News
>>
>> ------------------------------
>>
>> items, details further below:
>> BALUG meeting TOMORROW!: Tu 2018-07-17
>> giveaways (Books/publications, CDs/DVDs, ...)
>> New: Hardware, etc. wanted/offered!
>> help BALUG! :-) - volunteering, venue, ...
>> Twitter https://twitter.com/#!/BALUG_org
>>
>> ------------------------------
>>
>> For our 2018-07-17 (3rd Tuesday) BALUG meeting:
>>
>> At least presently we don't have a specific speaker/presentation lined
>> up for this meeting, but that doesn't prevent us from having
>> interesting and exciting meetings and discussions. We also manage to
>> sometimes secure/confirm a speaker too late for us to announce or fully
>> publicize the speaker (that's happened at least twice in the past).
>> Got questions, answers, and/or opinions? We typically have some
>> expert(s) and/or relative expert(s) present to cover Linux and related
>> topic areas. Want to hear some interesting discussions on LINUX and
>> other topics? Show up at the meeting, and feel free to bring an agenda
>> if you wish. Want to help ensure BALUG has speakers/presentations
>> lined up for future meetings? Help refer speakers to us and/or
>> volunteer to be one of the speaker coordinators. Great food and
>> people, and interesting conversations to be had.
>>
>>
>> Please RSVP if you're planning to attend. To do so please
>> e-mail us a note to rsvp(a)balug.org
>> indicating meeting date. If you'll be bringing additional guest(s)
>> please let us know total number of folks you're RSVPing for.
>> Also please let us know any special requirements or concerns you may
>> have (e.g. if you have any particular dietary considerations, so that
>> we might possibly be able to accommodate you, or if you won't be dining
>> with us but do wish to otherwise join our meeting).
>>
>> 6:30pm Tuesday, July 17th, 2018 2018-07-17
>> Henry's Hunan Restaurant
>> 110 Natoma St. (between 2nd & New Montgomery)
>> San Francisco, CA 94105-3704
>> 1-415-546-4999
>> http://henryshunan.com/
>> Easy Transit/Parking Access: short walk from BART, MUNI, parking
>> Trip planning: http://www.511.org/
>>
>> Delicious Hunan cuisine and reasonably priced.
>>
>> Meeting Details...
>>
>> Cost/Dining:
>> The meetings are always free, but dinner is not (unless you are our
>> guest speaker, in which case we also treat you to dinner). For
>> Henry's Hunan Restaurant, if folks are agreeable, we'll share and
>> dine "family" style, and split up the costs, and typical cost per
>> person including tax and tip (but not including beverages beyond
>> complementary tea) would be in the $13.00 to $20.00 range, and
>> commonly around $15.00 to $17.00. Cash may be preferred to ease
>> splitting up the check. One can also specifically order the
>> dish(es) one needs/prefers (e.g. for dietary considerations) - and
>> we also commonly order some dish(es) that may meet various dietary
>> considerations) (e.g. vegetarian, non-pork, ...). Please arrive by
>> 7:00 P.M., we expect to order entrees at that time, and may order
>> appetizer(s) and/or soup(s) anytime after 6:30 P.M.
Greetings!
Dr. Andreas Gros, data scientist at Facebook by day, and OLPC SF
volunteer is back from his recent visit to Ethiopia! He will be
presenting his project and updates, including the location in Addis
Ababa, the laptops being used by children there, and some ingenious
ways in which we have been working together to bring the "Internet in
a Box" to the kids there.
Come by tomorrow (Saturday) and get it straight from him :-)
Details and RSVP: https://www.olpcsf.org/node/266
Andreas Gros: https://research.fb.com/people/gros-andreas/
cheers,
--
Sameer Verma, Ph.D.
Professor, Information Systems
San Francisco State University
http://verma.sfsu.edu
Have a BALUG wiki page for
(Computer) hardware (etc.) offered/wanted
https://www.wiki.balug.org/wiki/doku.php?id=balug:offered_wanted_hardware_e…
It has some basic "rules of the road/guidelines" (see towards the top
of the wiki page).
If you want to list something(s) on there ...
preferred would be you get a wiki account and add/edit it yourself.
You can email me to get that (self-registration on the wiki site
has been disabled to thwart annoying spambot abuse).
Anyway, this may be rather/quite useful, rather than merely putting a post
to some (Bay Area) LUG list of some, e.g. hardware offered or wanted,
and everyone forgets about it later, or can't remember what the status
is, etc., or where the posting was ... well, now have a wiki page.
"Of course" folks aren't mind readers, so good to also have at least some
posting somewhere to call potentially interested folks at least initial
attention to it. But ... status, is it still offered/wanted, who
mentioned it, how to contact them ... well, wiki page seemed more fitting
and logical - at least to track that, rather than (merely) list posting(s).
And if you can't get/use wiki account to edit wiki page, for some reason,
and you just want to email me the updates ... well, maybe I can do the
edits/updates - if all the relevant information is provided, and that
doesn't get too unreasonable. But I'm not one's edit slave, so ... we'll
see how that goes (volume of such requests vs. what (if any) time I have
for such matters).
----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> -----
Date: Fri, 22 Jun 2018 14:18:56 -0700
From: Rick Moen <rick(a)linuxmafia.com>
To: conspire(a)linuxmafia.com
Subject: [conspire] (forw) Re: [License-review] Fwd: [Non-DoD Source]
Resolution on NOSA 2.0
Organization: If you lived here, you'd be $HOME already.
OSI had been pondering moving discussion of licence-approval discussion
to the 'issue'-handling software on GitHub. I mildly responded on OSI's
license-review mailing list that this might cost them some
participants, and why. The following e-mail side-discussion then
ensued, which might be of interest here and also bears on topics
discussed during this past week's BALUG meeting.
----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> -----
Date: Fri, 22 Jun 2018 14:14:34 -0700
From: Rick Moen <rick(a)linuxmafia.com>
To: [a valued friend on OSI's mailing lists]
Subject: Re: [License-review] Fwd: [Non-DoD Source] Resolution on NOSA 2.0
Organization: If you lived here, you'd be $HOME already.
Quoting [my friend]:
> On Thu, Jun 21, 2018 at 8:20 PM, Rick Moen <rick(a)linuxmafia.com> wrote:
>
> [1] More at http://linuxmafia.com/faq/Essays/meetup.html
>
>
> I duly read this essay and am moved to protest mildly and off-list.
Without particular objection, and with (as always) interest in what you
have to say, you're at some risk of arguing with positions I didn't
actually take in that essay. But let's get to particulars:
> While it's true that Meetup leaches (or leeches) data from its users and
> resells it, we make very similar agreements with "for-profit companies in
> New York" (where I also have the privilege of residing) as a condition of
> getting paid. The days of "The cash is under the MicroVAX" (which had
> wheels, as you may recall) are regrettably over. The ship of
> not-interacting-with-bastards has definitively sailed.
Life is always a series of thorny problems with grey areas, but I can
spot some sharp-ish lines among some that are not so.
Let us say that BayLISA had chosen to move its membership-facing Internet
operations to a VPS host. Technically, it would not _absolutely_
control its production infrastructure at that point, though it would
have had root, but from my perspective as a meeting attendee and Board
member, the difference in hosting would not affect me and I might not
even notice. BayLISA's contractual and business-operations dealings
with the VPS firm would be a back-end deal not adversely affecting me to
the best of my ability to tell. (At least, otherwise would require a
pretty far-fetched scenario.) So, the disgust I accumulated against
BayLISA's management policies around 2013 onwards would not have
applied.
Shifting the hypothetical, suppose instead that BayLISA had opted to
move its membership-facing Internet operations to a shared ISP host
where it had a few canned services (some virtual domain Web content,
Mailman mailing lists administerable only via CPanel, SMTP aliases
and webmail ditto, MTA services for the baylisa.org domain totally
inaccessible for administration except by ISP NOC people who don't give
a rat's ass about BayLISA specifically, and zero access to logs or
ability to configure Internet-facing software other than the few things
that can be tweaked to a limited degree using CPanel and the Mailman
admin webUI.
I have personal experience of this exact arrangement as the listadmin of
a local SF convention that made the horrific decision to move to shared
hosting at Bluehost, a Utah specialty WordPress-hosting vendor that does
an absolutely abysmal job at everything _but_ WordPress, and (among
other problems) is on about 80% of the SMTP industry's RBLs because of a
well-deserved reputation as a spamhaus (I gather, because they do
little or nothing to avoid scummy customers). In this case, I would as a
BayLISA member and Board member become moderately disenchanted with
BayLISA's hapless inability to run consistently run competent Internet
operations, with them continually falling back on 'Sorry, but our vendor
doesn't support that' as an excuse. Can't tell me why GMail appears to
be refusing all mail from the Bluehost MTA IP address? Sorry, we don't
have access to Bluehost's logs, and can't tell you what's happening to
the mail from our end. And why is it that BayLISA is forced to abandon
and delete the entire cumulative archives of Mailman mailing lists if
they need to be renamed or otherwise migrated? Sorry, our vendor
doesn't give us access to the underlying mboxes and we don't have shell
access on the shared server.
But, as bad as that situation would be, especially for a guild of
sysadmins to have to act that haplessly all the time, _at least_ members
and other users of BayLISA Internet services would not be required to
enter into contractual business relationships with Bluehost,
consent to one-sided terms of service with that firm they've never heard
of, and give away a big bundle of legal rights -- just in order to deal
with BayLISA. From the member / outsider perspective, BayLISA's
hosting may be lame and incompetent, but at least the outsourced hosting
would, like the VPS example, be a back-end deal, not one where the
member is expected to be a literal legal party on a take-it-or-leave-it
basis.
In this regard, a shared-hosting ISP like Bluehost has a _small_
sampling of the ills I detailed in my essay -- 'inflexible', 'is some
other guy), but not the rest ('nudzh', 'has the AOL nature', 'nosy',
'expensive'). As noted, the 'is some other guy' nature is merely the
normal 'back-end deal' variety where _you_ as a BayLISA member aren't
required to sign a contract with Bluehost, and the suckiness of
Bluehost's business services is ultimately BayLISA's problem and not
directly yours.
So grey areas, but in the shared-hosting case only a light shade of grey.
Add the rest of the ills, by making the outsourcing entity be
specifically a Web 2.0 network-effect-obsessed, pushy, nosy,
manipulative social-networking vendor like Meetup, Inc., and I maintain
that it's a really dark shade of grey for the external Internet user --
however convenient it might be to BayLISA as the (actual) customer.
The point of my hypotheticals is that my objection is specifically _not_
to outsourcing of Internet infrastructure to for-profit companies. It's
an objection to such outsourcing to a particularly obnoxious
subcategory typified by Meetup, Inc., for the reasons cited, and
expecting external people like me to put up with such firms, ones _we_
never decided we wished to deal with, being manipulated and treated like
product by them. My point to us external users is that we should
(and I do) stop putting up with that bullshit, and just say no. My
point to institutions like my former non-profit corporation, BayLISA,
Inc., is that, when you do that, the smarter and more-competent audience
you hppe to reach is rather likely at some point to get fed up and say
'Bite me'.
But, actually, as I said in the essay, that is not directly the main
thrust of the essay, fundamentally. The essay is merely a declaration
of policy about what sort of meetup.com-listed events I'm willing to
cover on the BALE calendar, which ones I'm not, and why.
(I make no apologies for taking a swing at BayLISA, along the way. They
deserve it.)
> In addition, whereas you can trust a corporation to be as evil as it says
> it will be, it is often the case that you cannot trust your fellow human
> beings not to be *negligently* evil.
So, let's talk for just a moment about contractual relations and the
implied covenant of good faith and fair dealing, and similar matters.
There's a fine point I continue to be curious about, and am unlikely to
get fully answered without the ability to abuse a Lexis account for a
long weekend -- but I'll mention it anyway.
I'm curious about how strong, how far reaching, how enforceable the
obligations of a Web 2.0 social networking company are to protect the
interest of users, given that the users are not paying for service.
On a practical level if not one of ultimate enforceability, I have
reasonable but not limitless confidence in the willingness and
competence of the ADSL provider, Raw Bandwidth Communications, Inc.
(that issues the upstream link and static IPs for my linuxmafia.com
server and my residence) to look after my interests as a customer,
provided that my interests and the company's do not excessively clash.
My money buys some (conditional) loyalty, _and_ I know that established
caselaw means that the firm's principal, Mike Durkin, knows that if he
acts in provable bad faith, I have strong remedies and not just the
ability to complain about him. (Mike has a sterling reputation
for customer good faith and also competence, part of the reason I've
remained a customer for decades.)
I do know that I'm somewhat at risk if Mike's company _were_ hostile, or
if Mike were served with a National Security Letter requiring him to
log and hand over all IP information transiting between his DSLAM and
my ADSL bridge device. (SSL and SSH mitigate the information leakage
potential, but No Such Agency would certainly get traffic analysis data,
plus anything sensitive I was stupid enough to put into plaintext
traffic.
What I'm wondering is whether my strong legal enforcement rights arising
from my paid-customer relationship with Mike's firm differ much from,
say, the rights of a non-paying GMail user against Google, Inc.
Yes, of course they do to the extent they are derived from contractual
details, where my contract with Mike is not one-sided, and a GMail
user's in laughably so. But beyond that? Taking as given that a GMail
user has a contractual relationship where he gives up something
qualifying as consideration (his/her privacy, if nothing else), is a
judge going to nonetheless side-eye a GMail user's complaints of Google
violating the covenant of good faith and fair dealing (and similar
protections) more than the judge would me if I sought recourse against
Mike's company?
I cannot say this for certain, and cannot point to any relevant caselaw
at all, but I rather suspect non-paying customers are likely to get
disregarded in court, in any such action, because they simply don't
come across as 'real' customers. My intuition tells me that the more
one's business relationship is structured as traditional
fee-for-service, the more one is likely to be able to successfully
assert one's right to equitable treatment.
Negligence among one's technical community is of course a dreadful
problem, but it is also a separate one that has its own obvious
remedies. The error or trusting everything to just one guy, and then
being surprised and disappointed when that guy breaks, is avoidable.
It is actually substantially _more_ and more easily avoidable in the
_technical_ community than it is in others. Failure to take those steps
in advance is a management/oversight failure, and IMO is the real
problem. I speak on this point in my capacity as a senior sysadmin,
where one of the difference between a junior SA and a senior one is that
the senior tends to know in his/her bones that 90% of professional
problems are rooted in people/planning failures.
> The Scheme community is missing a big chunk of its history because the
> mailserver during a critical period has gone offlline seemingly
> permanently, and the person who ran it is ghosting us, probably
> because he is ashamed to admit there are no backups.
The Scheme community failed to take basic steps to ensure that there was
functional, periodically tested failover to independent machine
resources, and also tested offsite backups.
Life is imperfect, so I know these things usually amount to 'We didn't
have time and energy to do more than a half-assed job, so that's what we
did', but, seriously, consider what the low-hanging fruit would have
been, just an afternoon's work on the failover problem:
1. Separate person sets up a *ix machine on static IP in his/her
(separate) premises. Today, this could be on a junk P4 or PIII.
2. That person coordinates with the first guy to do daily rsyncs
of all important data to the failover box.
3. In the ideal case, the failover box would also be fully configured
as a hot spare, but this is a fine point. It would probably suffice
for a few qualified experts to agree that all essential data are being
captured daily. If production host fails or the guy in charge goes
crazy, parties able to control DNS flip it, and if necessary there's a
mad scramble to make the failover host fully functional. The main thing
that cannot be done without is the data.
4. Some ongoing monitoring is required, to make sure failover
replication doesn't silently break.
For extra credit, once every six months, _deliberately_ flip the
failover switch. Nothing is quite as good at proving ability to
failover as doing failover.
When I hear a group of volunteers say 'We entrusted everything important
to one guy, never checked in any way, never arranged redundancy or
failover, and one day that one guy disappointed us', what I see is a
fundamental process failure. Didn't anyone else read Conrad's _Nostromo_?
> Since then, we are hosted on Google Groups, Github, and Bitbucket. Is that
> a risk? It certainly is, but in my judgment a lesser risk.
Google Groups doesn't have most of the list of ills I listed in my
essay. You can even subscribe a non-GMail, non-Googlemail e-mail
address to one, although Google, Inc. obnoxiously makes the information
about how to do that obscure and difficult to use.
As a result, if you look at the membership roster of a Google Group, you
typically find that either all or almost all members are using
GMail/Googlemail subscription addresses. There are a couple of these
operated by LUGs in the S.F. Bay Area where rick(a)linuxmafia.com (me) is
_literally_ the only subscriber not sucking off the teat of Auntie
Google for personal mail services.
I'm curious, did your Scheme community lose most of its non-GMail,
non-Googlemail users when it moved to Google Groups?
But, aside from that common... membership skew in Google Groups, the
passive-aggressive hostility to non-Google mail systems built into the
infrastructure, it's not a horrible choice for those not willing to just
put up a spare machine on a static IP and run Exim/Postfix and Mailman.
(_Plus failover_, if you have any common sense.) And on a quick glance,
exactly zero of my essay's list of Meetup's ills apply to it.
I wish to also make a point in passing about the _ease_ of arranging
backup and failover of relatively simple, commodity Internet services
like SMTP & mailing lists based on the GNU Mailman MLM: Here in the Bay
Area, I for many years hosted (and still host) on linuxmafia.com a
Mailman list for a San Francisco LUG called SF-LUG. During those many
years, I repeatedly pleaded with the leadership of that group to work
with me to set up periodic, automated backups of the membership roster
and cumulative mbox -- with no result except avoidance and excuses.
A few years ago, I had a couple of months of downtime because of an
improbable motherboard failure right in the middle of a major system
upgrade. This happened right immediately following my losing my job, so
I was a bit demoralised, and was then barraged by rather clueless
complaints from SF-LUG insiders, e.g., suddenly demanding copies of my
backup data but being unwilling to travel 30 miles to my house to get
it. (Apparently, I was supposed to drive to _them_, or something.) The
more the SF-LUG people barraged me with complaints and totally useless
suggestions, the more I put off rebuilding my server, which actually
wasn't that much work. I figure I delayed about two months longer
before bothering to fix the situation because of the annoying
commmunication than I otherwise would have, as suddenly I was rather
enjoying the vacation from running an Internet server giving
free-of-charge services to ingrates.
Tellingly, the reason I offered hosting to SF-LUG's mailing list in the
first place is that the main guy _had_ created a Mailman list, ran it
for a brief while, and had some sort of hardware failure that caused the
total loss of everything. Nobody had even so much as bothered to
occasionally copy the cumulative mbox off to a USB flash drive, which
would have been dead-simple and was totally flippin' obvious. The guy
was devastated and demoralised by the experience -- but, as became
apparent later, learned nothing. I wished the group well and so
gladly offered it a mailing list home to replace the lost one -- and
immediately got ignored, for years and years, as I repeatedly implored
them not to make _again_ the mistake that had destroyed them the first
time. Which rather tells you something, nei?
When I _did_ get my linuxmafia.com server back online after about four
months, a technical person _not_ among the somewhat useless people
heretofore running SF-LUG stepped forward and worked out _really simple_
means to make the membershop rosters periodically sent offsite. (He
also gave key help in recovering my server from its failed software
upgrade, which helped motivate me to bother.) For the rosters, it's a
simple weekly cron job that e-mails the rosters to a list of people.
For the mbox, it's (IIRC) an rsync cron job. Very simple, highly
reliable, _and_ provably that is totally sufficient to rehost the SF-LUG
mailing list if a meteor lands on my server.
Low-hanging fruit, you will note. Not clever, not even totally
comprehensive (e.g., subscriber-specific state data are not backed up).
But sufficient. As the late Adam Osborne of Osborne Computer used to
say, 'Adequacy is sufficient.'
As to GitHub and Bitbucket, my vague recollection is that public access
to the hosted repos is possible without a signup and login. The latter
entail, as mentioned in my essay, a new business relationship with
a company you never planned specifically to deal with at all, agreeing
to a one-sided service agreement, and being subjected to a bunch of
rules dictated to you by a bunch of strangers (who, again, you never
heard of otherwise or particularly wanted to deal with). If I were a
member of the Scheme community, and wanted, say, to share code, I'd have
a problem with that, and might very well say 'no, thanks'. I might then
treat the organised Scheme community as damage and route around it (RIP,
Mr. Barlow), e.g., share my code with other individuals via direct
exchange between their git repos and mine, and they would of course be
free to share that further with GitHub and Bitbucket if they're willing
to put up with corporate B&D, but that'd be not my problem.
I have an analogy from my own experience in the community: I'm a
longtime HOWTO maintainer with the Linux Documentation Project. About
five years ago, a new guy at LDP said that he'd decided LDP wasn't
going to process HOWTO updates via incoming SMTP submissions of SGML any
more, and we should all please just check them into GitHub.
I said, I don't have a GitHub account and have no intention of entering
a business relationship with GitHub, Inc. to have one. If LDP is
interested in my further HOWTO updates, I'm open to any other reasonable
arrangement, and perhaps someone on LDP staff who _does_ have a GitHub
account will be kind enough to check in my updates when I send them, as
always, to submit(a)en.tldp.org .
I've continued to do just that, and the mail gets delivered, but LDP has
not in the last five years bothered to check my SGML into its repo. So,
basically _now_ the more-recent versions of my HOWTOs and the SGML
source for them are available on linuxmafia.com and from anywhere that
chooses to mirror them (licensing encourages that), but LDP is ignoring
them. I figure it's their loss, and the community's, but that their
imposing of a sudden demand for external business relations was not
reasonable, and that the resulting damage to LDP from their poor
decisions was regrettable but ultimately self-inflicted.
----- End forwarded message -----
_______________________________________________
conspire mailing list
conspire(a)linuxmafia.com
http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----
Expanding audience beyond just the balug-admin mailing list.
----- Forwarded message from Rick Moen <rick(a)linuxmafia.com> -----
Date: Tue, 15 May 2018 15:46:49 -0700
From: Rick Moen <rick(a)linuxmafia.com>
To: Michael Paoli <Michael.Paoli(a)cal.berkeley.edu>
Cc: balug-admin(a)lists.balug.org
Subject: Re: BALUG list(s) unsubscribe
Organization: If you lived here, you'd be $HOME already.
Michael, let me recap points I made in our offlist discussion involving
trying to help the guy who insists unsubscribing 'doesn't work'. In the
case of such a user:
1. It's useless merely asking the subscriber 'What steps you're
following?', because the subscriber doesn't remember.
Comment: If you're serious, stress the need to _reproduce_ the problem
and take accurate notes.
2. It's useless merely asking the subscriber 'The error diagnostic(s)
(if any) you're getting', because the subscriber doesn't remember.
Comment: As above.
3. It's useless merely asking the subscriber to provide 'FULL EMAIL
HEADERS of an example message', because the subscriber has no idea how.
(Shouting doesn't clarify.)
Comment: The user may not even know what a 'header' is, at all.
If he/she does, the current ones look pretty 'full'; what does
'full' mean? They've probably never seen full headers, and wouldn't
know them from an anaconda. If you're serious, best solution would
be to provide two image files, showing the same message with truncated vs.
full headers, and say 'See how the full version has many your mailer
normally hides for simplicity? Notice the ones starting with
Received? Those and more are needed for diagnosis. Dig in your
mailer for a means to reveal them that might be called "Show
original" or "Show source", but might be called something else.'
4. It's pointless to admonish the subscriber to never furnish his/her
subscription password to the listadmins, as the listadmins have full
power to do mischief if they're Bad People, without such passwords.
And telling 'I can't unsubscribe' people that is just a pointless
distraction from their real problem.
Comment: Seriously, users haplessly mailing their subscriptions
around the Internet is very close to harmless to them. Them mailing
those to listdmins is _totally_ harmless. Neither risk is worth
dwelling on, especially in an instructional mail the user is already
going to find both challenging and a little offputting.
On points 1-3, I'm very, very much reminded of hard lessons learned from
CABAL's long history running public installfests. When we started doing
that in 1998, we brightly and optimistically hoped and expected
attendees would download and fill out a simple hardware questionnaire,
e.g., how much RAM, what CPU, how big hard drives.
As other 1990s LUGs around the world also found out, this was a total,
whopping flop. I think it flopped so hard that we deleted the
questionnaire out of sheer disgust, though some other early CABAL materials
survive here: http://linuxmafia.com/pub/linux/cabal/ Note in
particular the CABAL FAQ that Don Marti and I co-wrote: Some of that
excess optimism about attendees being able to pony up information about
their computers survives in parts of the FAQ.
The hard lesson was: They don't know. Which means, if you're serious
about getting that information accurately out of them, you need to
either teach them or furnish an automated software tool to gather it.
The best answer we got (to the questionnaire) was no answer. But some
attendees figured they needed to write down something to make the
organisers happy, so they took wild guesses about, say, how much RAM
their machines had, and tended to be hilariously wrong. (Needless to
say, guesses were worse than lack of answers.)
Why don't they know? Because they never bothered to figure out how
to get those answers, and didn't know where to start. Even though,
say, the POST RAM count whizzed by their eyes every time they booted
(well, until OEMs started hiding the POST process behind pretty
pictures), they lacked the curiosity to poke at the machine and
investigate to answer obvious questions.
But, the subtler problem: Sometimes they _once_ knew, but forgot what
they used to know, and figured a retrospective attempt to guess from dim
and fading memory was good enough. _You and I_ know that getting
reliable information from a computer means producing it
contemporaneously and capturing / writing it down _then_. But amateurs
make the error of trying to just remember this stuff -- _all the time_.
I had been co-author of 'How to Ask Questions the Smart Way' for untold
years when the insight of people totally failing to capture
contemporaneous diagnostic data hit me like a ton of bricks. I had kept
on, for years, trying to convey the right message to readers through
cute, clever word tricks like this 'Missouri' one in the essay:
Describe the problem's symptoms, not your guesses
[...]
Since the preceding point seems to be a tough one for many people to
grasp, here's a phrase to remind you: "All diagnosticians are from
Missouri." That US state's official motto is "Show me" (earned in 1899,
when Congressman Willard D. Vandiver said "I come from a country that
raises corn and cotton and cockleburs and Democrats, and frothy
eloquence neither convinces nor satisfies me. I'm from Missouri.
You've got to show me.") In diagnosticians' case, it's not a matter of
skepticism, but rather a literal, functional need to see whatever is as
close as possible to the same raw evidence that you see, rather than
your surmises and summaries. Show us.
Describe your problem's symptoms in chronological order
[...]
Users, even people familiar with the essay, kept posting their guesses
and not raw diagnostic data. Why? I figured it out: Because the raw
data scrolled off the screen and into fading memory, and the user wasn't
smart enough to go re-acquire it.
If I'd been in the room with that user, I'd have said 'What? Wait, you
_didn't_ go back and reproduce the symptom a second time so you can take
accurate notes? What sort of crazy approach is that? Why the hell not?'
But they don't know -- and, being remote from them across the Internet,
we can't see them screwing it up, and are unaware of them flubbing the
ground-level basics.
My real epiphany involved the least competent poster to the OCLUG
(Orange County LUG) mailing list, a guy who's always posting vague
requests for help and supplies about 70% of the mailing list's traffic.
At one point, he provided a supposed diagnostic message that was
_obviously_ grossly inaccurate for reasons including misspellings, and,
suddenly realising the key problem, I asked 'You typed that from memory,
didn't you?' He was a little cagey, but the answer was yes. I
patiently pointed out that helpers would be attempting to Web-search the
diagnostics, so inaccurate transcription was fatal. 'Oh.' And _why_
did he type it from memory? Because it just never occurred to him to
reproduce the problem (taking accurate notes, this time) _before_ asking
for help.
Remember: They don't 'get' these rock-bottom basics. Just not. If
they did, they wouldn't be in endless trouble. And frankly, anyone who
cannot figure out how to unsubscribe given help in every posting footer
and bountiful help on the Web is self-selected in advance for exactly
that kind of haplessness.
----- End forwarded message -----
More to be on web site soon, and then announcements ...
We've recently confirmed Elizabeth Krumbach Joseph for 2018-06-19:
the open source version: DC/OS (the datacenter operating system)
description and "slides" from earlier similar:
http://lists.netisland.net/archives/plug/plug-2017-08/msg00038.htmlhttps://princessleia.com/presentations/2017/Introduction_to_DCOS_PLUG_West_…
And this month - 2018-05-15 - don't have a speaker/presentation
lined up or confirmed, but I was thinking possibly, if we don't come up
with something else soon, perhaps discussion topic:
Security for Developers from a Sysadmin Perspective (notably
including: least privilege, permissions, users/groups,
isolation/containment, architecture, trust relationships, etc.)
... or how to tell developers & architects to plan/do accordingly to avoid
security pitfalls (other than the typical code booboos and weaknesses that
they're often relatively well aware of ... thinking more the "everything
else" - notably in the context of Linux - that they often don't think quite
as much about but ought more fully consider and be aware of).