Berkeley Pi: Getting ready for next week.

[tom r lopes]

So I have been thinking about how to make the Pi get togethers better.  

Problem is, It'd be nice to run the Pi headless so you don't need to lug around 

monitors and stuff.  But at a Cafe you don't have access to the router, so how do 

you find the Raspberry Pi ip address?  

So I thought to just bring in my own router.  

How about a Pi 4 as router!   So I followed the tutorial on raspberrypi.org.  

Now we have a Pi 4 with USB wifi dongle.  The USB connects to Cafe Blue Door 

WIFI which is then shared to the builtin WIFI.  

So the Pi 4 broadcasts a network as "Pihub" with a passphrase "BerkeleyPi"  

You can connect to Pihub and the Pi 4 does dhcp and bridges the connection to 

Cafe Blue Door WIFI.  I'll attach a screen with output of the dhcp so you can see the 

ip there.  

I still have to figure out how you'd distinguish between various Pi clients 

(maybe hostname?)  

So I'll be working on this tomorrow at the BerkeleyLUG meeting.  

Also sorry about the delay getting the Berkeley Pi website up.  I wanted to get 

WordPress working on a Pi 3.  I had trouble with getting the database setup and 

decided to take a break.  But now I think I know what I was doing wrong.  So I'll 

install Wordpress tomorrow if there is time.  

Thomas 

[Rick Moen]

Quoting tom r lopes (tomr...@gmail.com):

> Also sorry about the delay getting the Berkeley Pi website up. I
> wanted to get WordPress working on a Pi 3.

D00d.

If you can swing that, more power to you, but have you considered the
possibility that a simple static-HTML Web site might be orders of
magnitude easier to build _and_ maintain, not to mention require a
metric tonne less hardware resources from an itty-bitty embedded
computer?

Editing HTML5 in an ASCII text editor still works fine in 2020, y'know.

OTOH, if you really love WordPress, and are prepared to deal with the
absurd amount of overhead and recurring security meltdowns, then, hey,
you do you, sir!

--
Cheers, There's no theorem like Bayes's Theorem, like no theorem we know.
Rick Moen Everything about it is appealing, everything about it is a wow.
rick@linux Let out all that a-priori feeling, you've been concealing,
mafia.com right up to now. -- G.E.P. Box (w/apologies to Irving Berlin)

[ace36]

On Sat, Feb 22, 2020 at 6:50 PM tom r lopes <tomr...@gmail.com> wrote:

So I have been thinking about how to make the Pi get togethers better.  

Also sorry about the delay getting the Berkeley Pi website up.  I wanted to get 

WordPress working on a Pi 3.  I had trouble with getting the database setup and 

decided to take a break.  But now I think I know what I was doing wrong.  So I'll 

install Wordpress tomorrow if there is time.  

Besides getting up your (Tom's) Berkeley Pi website up, and if there is sufficient

further interest, then what are all of your thoughts to better promote the group's

social media presence through possibly setting up and maintaining Tom's

Berkeley Pi group accounts, e.g., on Facebook, on Twitter (modeled after

twitter.com/berkeleylug ), on Mastodon/Fosstodon fosstodon.org/@berkeleylug

... etcetera ??

There are already the pair of Berkeley Pi group event-specific webpages that

Tom L and Peter M already set up; https://www.eventbrite.com/e/berkeley-raspberry-pi-jam-tickets-91996019571

and https://www.meetup.com/Raspberry-Pi-SF-Bay-Area/events/nnqnnrybcfbcb/

Yes, still regularly review Rick M's thoughts on such social media-like

essay topics as 'INOLJ-OOW2.0C (Is Not On LiveJournal Or Other Web 2.0 Cults)'

http://linuxmafia.com/faq/Essays/winolj.html as well as his overall review of

Meetup.com at http://linuxmafia.com/faq/Essays/meetup.html

-A

[tom r lopes]

Yeah.  

Almost exactly what Michael told me, lol.  

--
You received this message because you are subscribed to the Google Groups "BerkeleyLUG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to berkeleylug...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/berkeleylug/20200223030313.GL18108%40linuxmafia.com.

[Michael Paoli]

> From: "tom r lopes" <tomr...@gmail.com>
> Subject: Berkeley Pi: Getting ready for next week.
> Date: Sat, 22 Feb 2020 18:51:13 -0800

> So I have been thinking about how to make the Pi get togethers better.
>
> Problem is, It'd be nice to run the Pi headless so you don't need to lug
> around
> monitors and stuff. But at a Cafe you don't have access to the router, so
> how do
> you find the Raspberry Pi ip address?
> So I thought to just bring in my own router.
> How about a Pi 4 as router! So I followed the tutorial on raspberrypi.org
> .
> Now we have a Pi 4 with USB wifi dongle. The USB connects to Cafe Blue
> Door
> WIFI which is then shared to the builtin WIFI.
> So the Pi 4 broadcasts a network as "Pihub" with a passphrase "BerkeleyPi"
> You can connect to Pihub and the Pi 4 does dhcp and bridges the connection
> to
> Cafe Blue Door WIFI. I'll attach a screen with output of the dhcp so you
> can see the
> ip there.
> I still have to figure out how you'd distinguish between various Pi clients
> (maybe hostname?)

So ... pi.berkeleylug.com - dynamic DNS updates - at least proof-of-concept
has been done. Can make that live for pi.berkeleylug.com in not too
horribly distant future (when I have some time, and Thomas is ready).
Could potentially even adjust to have clients be able to update their
own DNS entries - as subdomains of pi.berkeleylug.com (and
disallowing www.pi.berkeleylug.com - or anything else we'd want to not
let "any client" update for its own IP). But with RFC-1918 IPs,
might have to have that Rasperry Pi router do a wee bit more on that ...
or maybe have the clients just update on the Rasperry Pi router itself,
and it could also serve (augmented) DNS to the clients, and have
the clients update their DNS - for many/most dhcp clients that's also
the default behavior anyway - at least they attempt to update DNS
for themselves ... even the relatively standard Linux dhclient
does/attempts this.

Ah, and too, RFC-1918 ... not Internet addressable, ... but, IPv6, no
shortage of IPv6 IPs ... if the venue doesn't provide those, the
Pi router could initiate an IPv6 tunnel, and would then have plenty of
Internet addressable IPv6 IPs for the Pis at the event, ... and they
could update their DNS via dynamic DNS updates.

Also, I have the LUG DNS domains set up so anyone/anything can do
AXFR and dump the whole domain ... so that'd be fairly easy way to see
who/what is on the (sub)domain.

Oh, and if one does full routing on Pi to share upstream Wi-Fi &
(single) IPv4 IP, that may restrict bandwidth, as venue's Wi-Fi may do
(relatively) fair sharing among the IPs it has actively allocated.
Might be feasible way(s) to do that a bit differently, so the
Pi router doesn't reduce downstream Pis bandwidth through limiting to
a single IPv4 of the venue Wi-Fi, but rather uses and passes down (even if
NATed), one per (client) Pi.

Anyway, I may have to think about that some more ... and/or (likely)
someone has already figured out some good/slick solutions to this - and
relevant software/configuration and such, already.

[Rick Moen]

Quoting tom r lopes (tomr...@gmail.com):

> Yeah.
> Almost exactly what Michael told me, lol.

I also need to confess laziness in composing my reply to you -- sorry!
-- in that there are also attractive alternatives to _both_ flat static
HTML (maintained using ssh and a text editor) _and_ gargantuan,
dynamically generated, database-backed CMS and similar systems (like
WordPress).

E.g., people keep inventing nice, easy-to-use lightweight Web frameworks
where you edit human-friendly markup that is then batch-converted to
static HTML for display purposes. Problem is, I haven't kept notes on
their names, locations on the Internet, etc., so at some point I'll need
to run around reacquiring that information.

One example among many is former Debian developer (and personal friend)
Joey Hess's ikiwiki software: https://en.wikipedia.org/wiki/Ikiwiki


FWIW, Web content on linuxmafia.com is managed in a mix of ways:

1. Some pages are truly old-style vi-maintained static HTML. And
I'll admit that manually managing all those tags with their
angle brackets is irritating and a bit error-prone.

2. Some pages' maintainable files are in PHP, but that PHP is _not_
dynamically served to the Internet (because I long ago decided
a public-facing PHP interpreter and associated libs are an
unacceptable security problem). Instead, the PHP source is
used to generate a static HTML page that is then what's served.
This gets done (variously according to need) by either a cron job
(as with the BALE and CABAL pages) or by /usr/bin/make and a
Makefile that specifies how to knit the stuff together (as with
my personal FAQ pages).

3. Frequently, I start with stuff in flat ASCII (like the contents
of people's mailing list postings that I admire and wish to add
to the Linuxmafia.com Knowledgebase): To HTMLise them, I run
a one-off little parser in Python called convert.py, then, I
pipe the result through HTML Tidy to make the output more readable
and fix any HTML errors.

The above has been good enough to limp me along, but there are other and
probably better ways, elsewhere.