[TriLUG] newbie needs help with IP setup, part 2: static IP?

[Tom Roche]

Tom Roche Tue, 04 Dec 2007 16:54:32 -0500
 >>> I'm trying to setup a [FOSS] POS for my food co-op. That will
 >>> ultimately require static IP but for current testing DHCP should
 >>> work. Unfortunately I'm not getting even that,

but now I've got enough for testing each side of the POS one at a
time, thanks to Brian Henning.

Tom Roche Tue, Dec 04, 2007 at 06:27:07PM -0500
 >> * The POS [...] will ultimately need 2 static IP#s, in order for a
 >>   database box to talk to a "lane" box (to which a [customer]
 >>   display, scanner/scale, receipt printer, and cash drawer will
 >>   connect). These IP#s will go in config files for the POS app.

 >> * The friend who's hosting this

i.e. in whose rather cold basement the hardware is currently gathered
together, and via whose TWC Surfboard the hardware is currently
connected (via my ancient, dumb minihub) to the internet

 >>   has also acquired 2 domain names (for yet another project) from
 >>   godaddy, but hasn't done anything with them yet.

 >> So I'm wondering, how to get 2 static IP#s and make them work on
 >> this network

Brian McCullough Tue Dec 4 18:57:27 EST 2007 (rearranged)
 > What I am reading from your questions suggests that you are being
 > confused ( and the highly technical (!) answers aren't helping )

Don't tase me, bro !-) I'll try to be more helpful, within the limits
of my expertise. (FWIW I'm basically a user. I haven't setup boxes
end-to-end like this since 1998; more importantly I've always worked
in/on someone else's network, with either DHCP or public IP.)

 > by your needs and the equipment that you are working with.

Other than the Surfboard, with which I was unfamiliar, and the POS
peripherals (which are, umm, peripheral to this discussion) the
equipment is pretty straightforward: just 2 PCs that need to
communicate (more below).

 > What I understand is that you have a "store"

No need for the quotes--it's a brick-and-mortar store, established
1971. But in order not to confuse with "store" in the sense of
database, let's call it "the co-op."

 > where you intend to operate two separate "cash registers" ( Linux
 > POS boxes ).

No. See above (which you quoted): there's currently one "lane" (as in
checkout lane--"lane" is the term used in grocery IT, now that most
folks no longer use a standalone "cash register") and one backend. The
lane is where a cashier works and customers checkout, the backend is
in the office. The lane PC writes each transaction short-term to its
local DB (MySQL), then periodically flushes to the longterm DB (ditto)
hosted by the backend PC.

 > You wish ( need ) to have them communicate with each other

The POS *requires* the lane and backend to communicate with each
other. Here's some supported usecases <hoping this isn't too highly
technical/>:

0 A lane does a bunch of sales. At some point (e.g. change of
   cashiers) it handshakes with the backend and writes its sales to the
   backend DB. If that succeeds, the backend tells that lane to clear
   its sales table and start recording new sales.

1 Time to markdown some items: our manager updates the prices via the
   management interface on the backend. The backend tells each lane to
   quit doing customer transactions, pushes those updates to each lane,
   then unlocks it.

2 Time to pull sales into QuickBooks: the bookkeeper can run the
   report against only the backend. S/he need not access each lane
   (someday we expect to have more than one lane :-); in fact the lanes
   need not even be up.

 > If all you want, as you state, is _static_ addresses, in other
 > words, addresses that don't change and are associated with an
 > individual machine, you can easily do that using non-routable
 > addresses ( 192.168.x.x series would be good for you ).

To clarify the needs and wants:

* The POS requires static addresses (unless someone's willing to
   diddle the config files everytime a DHCP lease changes). I suspect
   we could enhance the code to communicate by name, but that is not
   supported by the current release (and would introduce a DNS
   dependency, no?).

* It would be very convenient to be able to access each box remotely
   while we're getting this setup. The POS' lead developers are in
   Minneapolis and Portland, and a fair amount of customization is
   usually required--co-ops have different membership structures/
   policies, states have different tax codes (there are no NC users
   currently), etc.

* Security is definitely more important once deployed. I believe a
   private intranet (on a cabled LAN) like you describe would be more
   secure (no?), so I'd like to learn how to set one up. (Feel free to
   recommend some doc, and I'll RTFM.)

 > Once we are agreed on your requirements,

In ascending order of preference:

0 My laptop, the lane, and the backend talk exclusively to each other
   on their subnet (i.e. "in the basement," currently). For that,
   static private (or direct-access only) networking should suffice
   (no?), but one would be required to be on the subnet to access
   anything. This is secure for deployment, but a PITA for development.

1 My laptop, the lane, and the backend can talk to each other anywhere
   in the world. For that static public (or remote-access allowed)
   networking is required (no?). This is good for development, insecure
   for deployment.

2 Enable toggling between private and public networking on demand.
   Normal mode will be for the co-op to run the POS privately/securely
   (no external access). But for development, or if we need the remote
   folks to get hands-on, we could enable external access (by changing
   POS config files, router config, etc).

Also all of the above hafta get done on the cheap :-( We do have my
volunteer labor (which may be fairly priced :-) for now. We don't
currently have IT staff (though we would if we got to a sufficient
size) and none of our current staff has IT chops (but we can usually
get volunteers).

Does this sound reasonable?

 > it will help us make more suggestions.

Suggestions are appreciated! TIA, Tom Roche <Tom_Roche at pobox.com>