Aura H2O Yet another telnet/sshd & misc tools package...

[NiLuJe]

As my device list attests to, I'm mostly a Kindle guy, but I nonetheless got a H2O for Christmas (mostly because the Kindle Voyage isn't available in France, but that's another matter entirely), and I of course had to 'port' all my Kindle crap to that new device .

Long story short, this is mostly the various tools I build bundled up in one big sack, with a telnetd/sshd setup.

Since I already wrote a readme inside the package, I'll leave the floor to myself:

README

This is basically a collection of all the custom binaries I use throughout my Kindle hacks,
but built for the Kobo, put in a single package, and symlinked (when not clashing) in the PATH.
That includes, among other things, stuff like less, htop, strace, ltrace, lsof, fbgrab, sqlite3, elfutils, rsync,
xzdec, zstd-decompress, lz4, ImageMagick, gawk, nano, ZSH, ag, tmux, GDB, gprof, perf, objdump, cURL, evtest, evemu,
FBInk, the full OpenSSH suite, jq, bsdtar, lftp, tree, file, dtc,
and a CLI Python 2.7 & Python 3.9 build with quite a few third-party modules (HTTPie, requests & co, Pillow, wand, ...).
And yes, just for kicks, there's also KindleTool in there ;D.
sshfs is also bundled, although Kobo kernels do not ship with FUSE enabled, so making use of it will require
building/installing the proper kernel modules, c.f. https://www.mobileread.com/forums/sh...5&postcount=66.

I still follow the Kindle spirit of "don't put anything in the rootfs if you don't have to",
so almost all of this lives in /mnt/onboard/.niluje, so don't be surprised if stuff goes missing after a factory reset .

It also provides ftpd/telnetd through inetd (following Kevin Short's KoboTelnet package), plus sshd w/ sftp (dropbear).
The dropbear build provides the same convenience features than my Kindle one (namely, persistent shared key auth:
the keylist is expected in /usr/local/niluje/usbnet/etc/authorized_keys).
There is *no* automatic USB networking handling here. WiFi only.
That said, you *can* manually toggle USBNetworking (provided your device isn't truly ancient), if need be:
c.f., /usr/local/stuff/bin/usbnet-toggle.sh for more details (in particular the fact that I'm using legacy Kindle IP settings ;p).
If you want an easy way to launch this script (besides in a shell via SSH over WiFi, as it's symlinked as usbnet-toggle),
see KFMon: https://github.com/NiLuJe/kfmon#how-...my-own-actions and/or NickelMenu: https://pgaskin.net/NickelMenu/ .

It also installs an udev rule providing a means to run an user-editable script (/usr/local/stuff/bin/stuff.sh) early during boot.
(AFAICT, that loop0 udev trick is used in a number of Kobo packages (David Beinder's kobo-nightmode and Andreas Klauer's AutoPatch, for instance),
no idea who got the idea first ).
This script is used to launch both inetd & dropbear.
Since everything is passwordless, running this on a public/open WiFi would be a *terrible* idea.
If you really need to, I'd recommend disabling inetd, setting up ssh shared key auth, making dropbear actually check passwords,
and locking dropbear to shared key auth only:
by removing the -n switch & adding the -s switch to its startup args, see the comments in /usr/local/stuff/bin/stuff-daemons.sh.

This touches neither rcS nor inittab, but if you already have an inetd setup in your inittab, you should probably clean that up, or it will clash.
If you have custom stuff in (or symlinked in) /usr/bin, take a closer look at what this package installs to avoid overwriting your own stuff.
This *will* survive FW updates .

NOTE: Since v1.6.N, the way Python is handled has changed a bit. Instead of shipping *everything* in the install KoboRoot tarball,
only the "core" stuff is bundled (i.e., everything except Python).
To install (or update) Python, make sure WiFi is enabled and will stick around (i.e., either via ForceWifi,
or by simply keeping the WiFi popup open), then run update-kobostuff
Ideally, do that in a tmux session: e.g., to install/update Python 3, run
tmux new -s kobo update-kobostuff Python
c.f., /usr/local/stuff/bin/update-kobostuff.sh for more details (including how to do offline updates).
It can also be used to update the "core" component, saving you an USBMS session and a reboot, and quite a bit of time,
as it will then use a much more efficient compression algorithm than the standard KoboRoot tarball.
Another major interest in doing it this way is that the compressed data will never make it to disk,
saving a few write cycles to the internal storage in the process .

To save space, both Python builds are shipped without compiled bytecode. Run python-setup to generate it.
Be aware that it could take around 5 minutes on slower devices...

Assuming you want Python, this *does* require a significant amount of free storage space (as each Python version requires around 150MB),
so make sure you have north of 400MB of free space for a full (Core + Python3 + Python2) install...
The update-kobostuff script should be taking care of checking that for you at install time, though.
That said, the actual core KoboRoot itself no longer bundles Python, and it should only require around 50MB.
And on that note, be aware than on slower devices (especially those using an internal SD card),
the "update" process can take a fair bit of time.

Tested on a H2O running FW 3.12.1 - 4.28.x, a Forma running FW 4.9.x - 4.28.x, as well as an Elipsa running FW 4.27.x - 4.28.x .
I'm fairly sure that this will *not* work on *really, really* old Kobo devices/firmwares:
basically, if your device is *not* running at least Linux 2.6.35.3 & a hardfp eglibc 2_15, don't use this.
TL;DR: It should work just fine for 99.9% of the population .

NOTE: Speaking of FW 4.17+, c.f., the entry about *nix hidden folders at the bottom of this page: https://github.com/NiLuJe/kfmon#things-to-watch-out-for
Because you'll probably want to tweak that setting *before* installing this .

NOTE: Kobo ships a glibc with no compiled locales. This is problematic, because it makes anything non-ASCII tricky to deal with...
c.f., http://trac.ak-team.com/trac/browser...fix-locales.sh for a quick recap of how to build some yourself.

Sidebar: If you need git, it's also available for installation via the update-kobostuff script (e.g., tmux new -s kobo update-kobostuff Git).
It's not part of the default package because, among other things, it has to eat a ~10MB chunk out of the rootfs...

-- NiLuJe ($Id: README 18694 2021-08-11 18:27:14Z NiLuJe $)

INSTALL

Copy the KoboRoot.tgz file found inside the kobo-stuff archive in the .kobo folder of your device.
Eject it safely, and wait for it to reboot after the "update" process.

NOTE: Like mentioned in the Python aside above, once installed this way, you can simply check for updates by running
tmux new -s kobo update-kobostuff Core
This ought to be much faster than doing the KoboRoot dance again.

DOWNLOAD

The current version is available here: kobo-stuff-1.6.N-r18901. [External link because it's slightly >20MB].


The build script, patches & toolchain config are in the x-tc tarball of my snapshots.

[scoky]

Very glad to see you become kobo guy
Thanks for your tools and I have used them in my kindle

[frostschutz]

Originally Posted by NiLuJe

AFAICT, that loop0 udev trick is used in a number of Kobo packages, no idea who got the idea first

I haven't seen anyone else using it.

The question is, if you do use it, why do you still modify the inittab?

[NiLuJe]

@frostschutz: I distinctly remember seeing the idea of using an udev rule to run stuff in various places, some of which appeared to be quite old. I can't think of any examples OTOH besides your AutoPatcher, I'll see if I can dig up specific examples once I'm back on my desktop. (EDIT: Definitely the night mode installer, at the very least).

As for the other thing: there's actually a TODO in the script triggered by the udev rule to switch to using start-stop-daemon from there ;o). I just haven't done it yet because the current method works, I'm not reinventing the wheel, and I didn't want to spend too much effort on all this anyway . But it's definitely in the cards, I've never been a fan of modifying system files on those things, which is why I originally started messing with this stuff back in the Kindle 2.x days .

[frostschutz]

Originally Posted by NiLuJe

(EDIT: Definitely the night mode installer, at the very least).

Nice. He even chose the same device for it

It's very clean to get scripts started at bootup. And mods that use this method don't clash with one another (unlike doing something like a rcS modification, where only one mod survives).

Nice tool collection, I just grabbed strace from some Debian package that happened to work; SSH I don't need (the Kobo only knows my local wifi - unless it autoconnects to unprotected ones?), but it's bookmarked at any rate.

Actually, one tool I could use is sqlite3 for the database. Provided it doesn't crash if modified directly on the reader - sqlite itself normally can handle it but you never know.

I already have a script that creates shelves and series information from the directory structure (although it only works with my own idea of directory structure I guess), but there's no readily available sqlite3 client to actually get the necessary queries executed on the DB...

Haven't found the time yet to compile it myself (or see if the Debian version works)

[NiLuJe]

@frostschutz: Yep, it's a pretty neat way to handle this kind of stuff. I was a bit wary of the timing at first, but seeing that /mnt/onboard is mounted at that point is good enough for me .

The strace build has a whole history related to KOReader and figuring out what the hell nickel is doing with the eInk driver, it should be a bit more tailored to the actual Kobo kernels than a generic build, especially on the eInk front . fbgrab also comes in handy from time to time .

I haven't checked how it behaves, but that sqlite build (be it the standalone client or the Python module) should come with all the bells and whistles (the Kindle sqlite setup demands it, Amazon even went so far as using the modular capabilities to implement custom functions). That just leaves seeing how well nickel handles having the rug swept from under its feet .

[NiLuJe]

Okay, just got rid of the custom inittab, everything's now started w/ start-stop-daemon from the script triggered by the udev rule .

I'll update the package once I'm done rebuilding stuff to fix a minor issue with the default PATH in dropbear .

EDIT: Done. Bumped to v1.1 .

[frostschutz]

Originally Posted by NiLuJe

I was a bit wary of the timing at first, but seeing that /mnt/onboard is mounted at that point is good enough for me .

Actually, the /mnt/onboard mount happens only after udev is started, so it's entirely possible it won't be mounted yet. There are also some corner cases (factory reset / firmware update).

So if you execute a script on /mnt/onboard/ there might be a possibility it won't run. Not sure if udev waits for such things at any rate. A script in the internal memory, it's probably worth checking that /mnt/onboard/.kobo or whatever actually exists.

[NiLuJe]

@frostschutz: Yep, that's exactly why I was afraid of the timing. So far, it appears to work fine on my device (somehow ;D), but I might just have been lucky.

I'll tighten this up.

EDIT: Done. Ended up moving dropbear & busybox out of the vfat partition, so that simplifies everything, and I now feel better when onboard is exported over USBMS, since these things are so finicky. Bumped to 1.3 (1.2 was the intermediary iteration w/ a wait-for-onboard bit of logic).

[boriar]

Originally Posted by NiLuJe

@frostschutz: Yep, that's exactly why I was afraid of the timing. So far, it appears to work fine on my device (somehow ;D), but I might just have been lucky.

I'll tighten this up.

EDIT: Done. Ended up moving dropbear & busybox out of the vfat partition, so that simplifies everything, and I now feel better when onboard is exported over USBMS, since these things are so finicky. Bumped to 1.3 (1.2 was the intermediary iteration w/ a wait-for-onboard bit of logic).

The link in the first post download the old 1.0. Can you fix it?
Thanks

[eschwartz]

https://storage.sbg-1.runabove.io/v1...-r11391.tar.xz

[boriar]

Thanks. That's a quick answer

[eschwartz]

I know what NiLuJe's links look like. He uses the same host for his Kindle snapshots.

[NiLuJe]

Wow. I'm awesome. I managed to update the link text but not the URL itself ;D. Thanks @eschwartz .

[NiLuJe]

On a slightly related note, I updated my standalone FBGrab build with my latest changes.
Among more verbose info and a proper Kobo build, it will also automatically crop the top 11 pixels on a H2O (what's behind the bezel). I did not do anything for the Aura, because I don't have one and I'm not exactly sure if something like that is needed, so if anyone with an Aura has time to spare, I'd be glad for a random snapshot taken w/ fbgrab, and the output from fbgrab -v .