Hi Andrew,
On 12/2/2011 4:00 PM, Andrew Smallshaw wrote:
> On 2011-12-01, Don Y<not.to.be@seen.com> wrote:
>>
>> Interesting. I use CA5's for Xterminals and have been
>> wanting to repurpose some CA10's (1GHz/1GB) for other
>> bits of fabric (firewall, name service, etc.) but
>> have yet to make time to design a CF adapter that
>> will fit in the thing (connector points the wrong way).
>> So, throwing laptop disk drives does the job without
>> much effort.
>
> I wanted to avoid a disk at all costs. One of the main motivations
> for using a thin client in the first place was for a completely
> silent machine so it removes one source of potential distraction
> (or possibly, it removes one potential excuse).
Agreed -- for an X terminal. It's delightful being able
to hide the noisey machines (real servers) elsewhere and
concentrate on the work at hand... *soft* music in the
background instead of being forced to wear headphones, etc.
But, I've had small machines providing "key services"
tucked under a dresser in the bedroom for more than a
decade. SPARCstation LX was my favorite in this role
(*reasonably* quiet -- if you used a new-ish disk -- and
low power... not like the majority of PC offerings).
Given its unfortunate location (think: sleeping), it is
probably an even *better* candidate for "silent operation".
[unfortunately, the LX just didn't have the horsepower
to keep up with my routing needs as more nodes and
networks came online :< ]
> In any case there's
> no room for an HDD in the CA21 case.
It looks like the CA21 is about the size of the CA5.
The CA10 is probably twice that volume. E.g., it
supports a single PCI slot, has provisions for a
PCMCIA option on the PCB (i.e., lots of real estate),
etc. A laptop drive fits easily.
The PCI slot and dual DVI+VGA connectors (it will
run dual headed) are the real draw, for me (plus the
fact that they were freebies). E.g., I stuffed a
4NIC PCI card in the firewall box so it can straddle
the routing between *all* the networks, here (WAN
on one NIC, wireless AP on another, "traditional"
computing on yet another and automation and
multimedia on the last two).
I'd like to deploy some of the others for various
"dedicated" roles on those other networks (e.g.,
media services, etc.) but those apps tend to be
more (persistent) stateful...
> The "right" sort of CF adapters are available but you a lot of
> searching and sorting out to isolate the correct ones - it doesn't
> help that a lot of sites don't seem to fully appreciate the
> differences between form factors so don't provide the necessary
> details unless you're willing to scrutinise images for detailsa
> couple of pixels high.
Exactly. Where is pin 1? Which direction will the card
extend into the case (the IDE44 connector is located on
an edge of the board so if the adapter mounts "the wrong
way", you can't plug the adapter into the connector due to
mechanical interference with the case)? Will the CF card
sit *on* the adapter or hang below it (interference problems,
etc.)?
Unfortunately, I only have one or two of the original
"modules" (which, of course, are designed to fit very
nicely into the space provided). They are a bit smallish
(i.e., imagine fitting a "flush" set of choices for
xfs on that card!) and have XPe on them currently.
>> How did you decide what parts of the system needed to be
>> tweeked to get it to run R/O? E.g., mount an MFS for /var
>> (and probably cut down on logging and/or set newsyslog.conf
>> to compress and discard logs, *often*).
>
> Just /var and /tmp on MFS mounts, the former of which is populated
> from a tar file at boot time. I haven't seen the need to trim
> logging: since these are used as terminals they get powered off
> and reset at the end of the day anyway.
Understood. In my case (firewall, DHCP, DNS, NTP, xfs, etc.)
the whole point was to leave them running 24/7/365 so that
any *other* machines could avail themselves of those
services as/when needed. All of them tend to *want* to
scribble notes someplace -- or, be easily reconfigurable
as needs change.
>> Do you run many *real* apps on the boxes? Or, just use
>> it to host an Xserver?
>
> Not really. Mostly it's X querying the relevant machine with XDMCP,
> or running rdesktop for when I need a Windows machine. SSH, telnet
> and Minicom (to a serial console server) for command line stuff.
> I have experimented with local apps and most things I use are fine.
But you remotely mount a $HOME, etc. (?) Something I can't
do as *this* is supposed to be the system that others
depend upon (i.e., the bottom-most turtle).
> OpenOffice takes a while to load (perhaps 15 seconds) but it fine
> after that. The only problematic app is Firefox - it's slower than
> a dead slug. That's a pretty big limitation for me and I suspect
> a lot of users - I need a web browser even for a couple of in house
> databases.
Ah. The only time I tend to use a browser on an X terminal
is for Solaris/Jaluna help/man pages. I should try it, though.
With 1GHz and 1GB and Gb fabric (though I think the CA10 only
runs at 100M??) it should be a client-side limitation.
(i.e., not *running* the browser on the X terminal iron
but just using it for display services)
>>> I did take a couple of months to refining that installation to
>>
>> -------------------------^^^^^^ Ouch! Hence my reluctance to
>> tackle this (until I've decided that the CA10's are, indeed,
>> the right platform o which to invest that time)
>
> I'll re-phrase that. A couple of months to _get_around_ to doing
> the job properly. Perhaps half an hour to sort out when I finally
> did. There are plenty of examples around online you you look in
> the right places: it is essentially similar to the way live CDs or
> even installation media work. There's also a guide on this very
> scenario at http://www.bsdnexus.com/NetBSD_onastick/install_guide.php
I see the bigger problem being the effort required to determine
what the applications (that will be hosted on that diskless iron)
expect in terms of writeable file systems. E.g., long running
services *will* tend to create bigger log files, you'll *want*
those logs (since the box is providing key services), apps
may need to update persistent configuration data, etc.
I was chagrined to discover that PostgreSQL won't support
a R/O database -- even if you never MODIFY it's contents!
E.g., I had planned on keeping the catalog of music
selections in an R/O database for the multimedia server
(which I wanted to host using another of these silent,
fan-less boxes) so that it (and the music itself -- though
requiring external media to store due to size) was
accessible whenever a user wanted it (i.e., 24/7/365).
The fact that it apparently must reside on R/W media
(even though it is never deliberately modified) made
that a considerably harder challenge.
[desktop applications seem to have a cavalier attitude
towards resources: they expect them to be limitless
and, at the very least, have NO IDEA what their actual
requirements might be!]
>>> read-only operation during which it had no real issues though,
>>
>> So, root is *mounted* R/O? As such, anything that you
>> may have "overlooked" will eventually cause a panic?
>
> Yes, and I wouldn't expect panics either.
Unlike a *real* embedded system, there don't seem to be any
details available that tell you just how much memory the
kernel will call upon in whatever situations it is likely
to encounter with a given set of apps running on it.
Since it makes no sense to have swap on a device like this
(mount swap on an MFS? why not just use the underlying
memory behind the MFS for physical memory??![1]), any
time any set of kernel+apps exceeds the total physical
memory available...
[1] Actually, wrapping memory in an MFS with a co-resident
swap (like Solaris' /tmp) can make certain configurations
of apps more "runnable" (without altering sources).
I would *prefer* the panic (at least while shaking out the
various bugs in the configuration) as that draws immediate
attention to each (new?) problem. Easier to notice than
having to parse *.error syslog entries. :-(
> Userland issues, sure,
> although the only problem I recall is with the SSH client and its
> authorised keys file - the home directories for some users are
> read-only too.
>
> I think I'd better explain that, since there are two classes of
> login. The first is conventional logins whose home directories
> are NFS mounted so there's no issue with those. However, I also
> have some pseudo-users with home directories in /usr (root filesystem).
> They have logins names of various systems, no password and when
> logged in their .profiles fire up X and connect to the relevant
> system. Crude but a hell of a lot more straightforward than some
> graphical front end.
Understood. I manage my ssh, telnet, etc. connections
similarly (and make a point to change $PS1 to `hostname`
everywhere to remind me of who I'm talking to!)
> However, when SSHing directly out of the
> machine it tends to be as myself, so I have an writeable home
> driectory anyway.
Is *your* $HOME NFS mounted? Or, "volatile" in an MFS?
I.e., can you *do* anything with *just* this machine up
and running (and no others)? E.g., I can (currently,
owing to the presence of the laptop drive) fire up a
CA5 (as an X terminal) and "work" (run apps) on the CA10
(I often use this to *write* code that I don't yet need
to compile... when I don't want to deal with starting
any bigger iron).