A Blog that fit’s in the Pocket
A Very Tiny Blog — (machine)
Continued from page 2:
WordPress can’t get along without some definitions in the wp_config.php (the configuration) file. This is because it usually has a user, password, and so forth, that needs to be passed to the database. In the case of SQLite, there are no such security related things. But, I needed to create phantom definitions anyway:
- define (‘DB_NAME’,’sqlite’);
- define (‘DB_USER’,’sqlite’);
- define (‘DB_PASSWORD’,’sqlite’);
- define (‘DB_HOST’,’sqlite’);
- define (‘DB_CHARSET’,’utf8′);
- define (‘DB_COLLATE’,”);
- define (‘DB_TYPE’,’sqlite’);
As before, I have to say that there are plenty of other options (mostly not related to sqlite) that can be specified in wp_config.php – but I’m not going to begin to ellaborate on any of those.
Technically, one can encrypt data before it’s put into the Sqlite file. And – there are mechanisms for doing this (sqlcrypt). I don’t think that any such thing has been worked into the Sqlite related plugins for WordPress however. As I said, mine is a private server, so access is limited elsewhere.
Making the Access Point Easy
So, another thing I wanted to do is to make the access point an easy connection to do. So, a friend sees the access point beacon line in his or her client machine’s login window, clicks it, and uses the normal one or two click and a password connection routine. Following that, what does a visiting friend do, in order to see something in his/her browser (my blog, for instance)? My pocket blog machine has a dhcpd daemon, so the IP assignment is requested automatically (usually) by the machine that’s logging in, and the dhcpd daemon dutifully hands out an address. But, then what? I have to tell the visitor what to type into his/her browser bar. Nonsense! Also – that’s too much effort for an effortless login procedure.
So, I modified the unbound caching resolver that runs on the pocket blog in a way so as to faciliate automated browser connections. I configured it so that no matter what URL a user types into the browser address bar, the same IP address is returned to the browser, and hence the same default index.html page. I have a simple html page called the “Sailor Hutch Vessel Redirection Page” configured via the Hiawatha webserver, to be the default page that is served when a valid virtual host name is not specified in the browser-sent URL header.
So, they (the visitors) can type anything (well, any dot-com address) into the address bar and still they will reach my blog startup page. This is what coffee shops and internet cafes do all the time. It’s just that the regular blog guy rarely has a reason to do pretty much the same thing. Since most browsers automatically go to some browser related URL when they launch, it too is redirected to the startup page, without they’re having to type anything at all into the address bar. Nice.
This “startup page” I make reference to, details the point that the access point they have reached is a semi-private access point, and that after any connection to the AP, all navigation is directed to my blog pages and to similar stuff. It mentions that the AP does not connect to the internet in any way, so the blog is the only content. On the same page I’ve put a link which they may click that takes them to a valid virtual host (also set up in Hiawatha’s config) – and so they go directly to the WordPress pages.
So, it’s a log in, and then just one more click to arrive at their destination. Since they’re friends who are visiting, I don’t demand indentured slave work from any of them or from their children for the blog access. But, I DO put my standard disclaimer that I’m not responsible for anything on the page, or what it does to their computer. And NO – I don’t have anything they should worry about, so far as I know. Here tho, for this blog page, I must put my standard “these configs may or may not work, and may or may not be correct” disclaimer.
So, here’s some details. First, the unbound configuration:
- local-zone: “com” redirect
- local-data: “com 10800 IN NS ns.steelieschooner-ap-virtual.sea.”
- local-data: “com 10800 IN SOA ns.steelieschooner-ap-virtual.sea. nobody.invalid. 1 3600 2400 604800 1024”
- local-data: “com 10800 IN A 192.168.1.52”
- local-data: “ns.steelieschooner-ap-virtual.sea. A 192.168.1.52”
- local-data: “www.steelieschooner-ap-virtual.sea. A 192.168.1.52”
I probably wouldn’t have needed to supply so many subdomains and record types, but it doesn’t hurt anything (that I know about). The first five lines are relative to redirecting all dot-com traffic, and the last is for the wordpress site itself. Not all of the unbound config is shown, but only the snippet for redirection. This takes care of dot-com domains, but other TLDs (i.e. dot-org, dot-net, etc could be added if desired. I tried various schemes such that I wouldn’t need separate TLD definitions, but unbound seemed to bulk at that idea.
The thing to remember is the dot at the end of the domain names. The dot says that the name is a fully qualifed (FQDN) domain, whereas the “com” is not a FQDN (as it is only a part of many possible domains). The SOA (start of authority) probably isn’t needed for this simple setup, but hey – with the SOA it’s more like the real deal.
Note: WordPress is under the guardianship of the WordPress Foundation, and WordPress.com is a service provider owned by Automattic, Inc. Neither has any association with this author, even though this blog is hosted there! This author is making no claims whatsoever about the accuracy of the given info, or whether or not the configurations are correct.
Hiawatha webserver is a nice piece of software maintained by the people (actually I think it is one person) – at hiawatha-webserver.org – and they have no affiliation with this author or site. Likewise, SQLite and its author(s) have no relationship with this site.