Author Topic: R.Pi "original Model B"--possible CathInfo use (Read 1086 times)

AlligatorDicax · « **on:** June 02, 2016, 12:23:14 PM »

Quote from: Matthew (Mar 11, 2016, 7:05 pm)

I only have the original Model B -- not even the B+.  It's a bit slow for running Raspbian, which is why I stopped using it. [....]  Now that there's a Pi 3, I want to use that old "original Model B" even less. I don't know what I'm going to do with it, actually.  Maybe I'll find a use.

Quote from: AlligatorDicax (Mar 17, 2016, 5:00 pm)

Raspian on a 700 MegaHz ARM (11?), equipped with the 256 Megabytes RAM of what I've seen identified as the "Raspberry Pi 1" "model B rev 1" [...]?

Quote from: Matthew (Mar 17, 2016, 11:47 pm)

The original model B had 512 [MB] RAM, which is truly a minimum for trying to run a GUI like Raspbian.  [...] I realize we used to get by with much less (the first PC my family owned -- when I was old enough to drive -- was a 386 16 MHz with 2 MB RAM.  I used [PC|MS-]DOS though, I didn't even bother with Windows 3.1 since the machine couldn't handle it.)

Ah, yes: The reduced-capability unix-inspired command.com language (as laundered thro' CP/M) for PC|MS-DOS, possibly as far back as its version 3.3 (1987), altho' maybe not until ver. 5.* (1991--). And I'd be really surprised if in your years of using linux to develop & operate Web sites, GUI shells had become so dominant that you'd avoided gaining substantial experience with unix-derived line-oriented shells.

Would it be worthwhile for you to configure your "model B" of undisclosed "rev"-number so that you could set it aside as an (emergency) server for CathInfo?  Perhaps stripped down for the primary--or only--purpose of answering all HTTP requests to CathInfo by serving a very simple Web page that presents little more than a straightforward "out of service" message.

[My XHTML & SSI code to illustrate the simplicity of the Web page I had in mind, as originally drafted, ran afoul of 1 of the new server's security rules, so I've extracted my recoded version for posting separately in a few minutes (just in case the combination of Matthew's response and my recoding doesn't completely resolve both sides of the problem).]

This fall-back server would be useful only when whatever caused the failure of the CathInfo site left you with this:
· operational downstream & upstream Internet connection (unlike the failure Tue., May 31 

); and

· operational A.C. power from the public grid.

Could your "model B" run any of the reputedly light-weight servers (e.g.: lighttpd or nginx) efficiently enough to handle the above fall-back response to the amount of traffic that CathInfo typically receives?  Could it handle what might be your all-time record of traffic (the day "Benedict" Ratzinger resigned, wasn't it?)?  If you obtained a GUI-free only-line-oriented-shell port of linux to the Pi 1 (or stripped out the Raspbian GUI, leaving or installing only a command-line shell), you might be able to operate the "model B" well enough to avoid the power demands that would be imposed by an HDMI monitor. I'm assuming that you could run rsh or ssh on the "model B" from a linux-bootable laptop, or maybe--just maybe--from an android smart-phone (if any of the latter are equipped with adequate external connectors).

I'm assuming that you'd write a shell script that uses linux sed for modifying & updating the message provided on the fall-back Web page. It'd be desirable to have for the fall-back Web page to display a time-of-day dynamically updated in each instance of the Web page (thus most of my SSI syntax [to be posted shortly as indicated above]), so site visitors could plainly see that they weren't repeatedly pulling your fall-back page from their own browser caches.

Once CathInfo members became comfortable with--or at least become conditioned to avoid panic from--unexpected appearance of the fall-back Web page, especially reässurance from observing ETR guesstimates that are reliable enough for the free forum that you're providing, it might reduce your occasional stress as owner-admin, such as what you reported recently when you needed an opportunity to install the newer replacement power supply in your new server (Wed., May 25 [##]).

-------
Note *: Matthew: <http://www.cathinfo.com/catholic.php/Raspberry-Pi-3-model-B#p1>. Posted "Mar 11, 2016, 7:05 pm", &seq.

Note #: Matthew: <http://www.cathinfo.com/catholic.php/Expect-some-CathInfo-downtime-15-min>. Posted Wed., "May 25, 2016, 12:30 am".

Note ##: Matthew: <http://www.cathinfo.com/catholic.php/Sorry-about-the-outage-Texas-monsoon-season>. Posted Tue., "May 31, 2016, 7:11 pm".

AlligatorDicax · « **Reply #1 on:** June 02, 2016, 01:16:04 PM »

[This posting provides my XHTML & SSI code to illustrate the simplicity of the fall-back CathInfo status Web page I had in mind, as I recoded it for posting separately (just in case the combination of Matthew's response and my recoding doesn't completely resolve both sides of the problem).]
[The MercuryBoard BBS as used on CathInfo seems not to provide the 'pre' & '/pre' tags that facilitate display of coding for software, altho' prettyprinting the XHTML & SSI would've added indentation via white-space, likely undesirable for this exercise in minimalism.]

<html>
<head>









<title>CathInfo status via temporary fall-back server.</title>
<meta name="description" content="CathInfo status page served by CathInfo's temporary fall-back server.">
</head>
<body>
[]
<br />The primary server for <b><big>CathInfo</big> is temporarily down</b>:
<ul>
<li>
The estimated time to repair (ETR) is presently .
</li>
<li>
The electric power now available to the CathInfo bunker is from .
</li>
</ul>
--Matthew
</body>
</html>

Only 1,016 bytes to serve: no more than 2 segments of IPv4 default-size, leaving 56 bytes to spare, and that before SSI substitutions reduce it further.

Maybe it would be desirable to have this fall-back server also send the 6,056 bytes of the CathInfo logo (the code shown above does not incorporate what's needed to display it), altho' doing so would require 12 more segments of default-size, which would increase the data transmission by a factor of 6 (i.e.: making the overall page transmission a factor of 7 times what's required by the simple text-only page as coded above).

If I've made fundamental or subtle errors in how I've quantified all this, correction is hereby solicited (altho' I might have removed a few of my CR LF pairs in continued lines without recalculating the shortened length).