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

[davidfor]

Originally Posted by chech

hello i'm looking for a use a browser-based application on my kobo h20 my problem is that the internal browser does not support localstorage suddenly i can't be used the application i guess the kobo store uses some kind of localstorage to preferences I tried a lot of things without succeeding too much kvncviewer m displays a half screen for 30 seconds I guess we can change the link address for kobo it is a local network on a boat and an application which allows to postpone the data of the on-board computer all open source I have successfully modified an application in sessionstorage and it works moderately not being a developer you explained if you have an idea thank you very much

What firmware version are you using? Something did change in 4.20.x and there is now a "webstorage" directory created in the .kobo directory. This has a set of files with the extension "localstorage" and names that based on URLs. The files are SQLite databases. They appear to contain data from websites. Beyond that, I don't know much as I don't try to use the browser for anything complicated.

But, overall, the browser is simple. The device is a low powered device. And the browser reflects that. It is not intended to be a full function browser you would use on a PC or a tablet with a reasonable amount of power. The device is an ereader. It is intended to be a single function device, not a general purpose computer. It does one thing well, and everything else not so well.

[chech]

Originally Posted by NiLuJe

This has nothing to do with this, so, create a dedicated thread?

And try a search first, people may have already tried a few things with the browser (I wouldn't hold my breath, though, it's a pretty ancient webkit version).

(Also, punctuation helps. Walls of unreadable lowercase text won't help your cause.)

i 'sorry think you for your response i m french and not good with the grammar . i open a new tread but i take a lot off hours to search in the forum the good way and i see you are very good to mod the kobo think you have a good day.

[chech]

Originally Posted by davidfor

What firmware version are you using? Something did change in 4.20.x and there is now a "webstorage" directory created in the .kobo directory. This has a set of files with the extension "localstorage" and names that based on URLs. The files are SQLite databases. They appear to contain data from websites. Beyond that, I don't know much as I don't try to use the browser for anything complicated.

But, overall, the browser is simple. The device is a low powered device. And the browser reflects that. It is not intended to be a full function browser you would use on a PC or a tablet with a reasonable amount of power. The device is an ereader. It is intended to be a single function device, not a general purpose computer. It does one thing well, and everything else not so well.

hello i see this but it s very good display fo a little dashboard in marine application i test with an app for kindle but its difficult to program what i want read on it my project is to just see a decimal number whith about 1 second off refresh. thinks

[davidfor]

Originally Posted by chech

hello i see this but it s very good display fo a little dashboard in marine application i test with an app for kindle but its difficult to program what i want read on it my project is to just see a decimal number whith about 1 second off refresh. thinks

If that is what you want, then people have done some development for this. I remember someone creating an app to view the speed and possibly other things for yachting. The creator reported some success, but, I haven't seen any mention of it recently. And there has been plenty of discussion of similar things. Starting a separate thread and giving details of what you want to do is the best thing.

Edit: Which I know see you have done.

[NotANormalNerd]

Hello @NiLuJe,

First off, thanks for the amazing package. After getting everything running, hacking on Kobo is so much easier.

I am trying to use the Kobo Touch (Mark3) as a display and hacked a little on the YAWK:
https://github.com/NotANormalNerd/yawk

I also just saw the Kobo Dashboard, which I will have a look later:
https://github.com/Mavireck/Python-Screen-Stack-Manager

I got everything running, the script isn't running smoothly but that is just some smaller issue with the script on a flaky Internet Connection.

I have one request, since I am a senior Python Developer but a really bad C/C++ Developer or even toolchain user. So starting to crosscompile stuff for the kobo would take me much, much, much, more time.

So, asking nicely: Would it be possible to add git to you tool package. I could fix the kobo to the wall and just pull from the github repositories onto the onboard card, or even run a deamon that pulls stuff on triggers, via telnet.

If there is anything I can help with, or if there is a documentation on how to crosscompile for the Kobo Touch, I would be very happy to help or do it myself.

Best regards,

Dennis

[NiLuJe]

I'm a bit loathe to actually add it to the package, because it's a shitload of small binaries, but I can certainly try to whip-up an add-on tarball, the only missing dependency appears to be pcre2, which is self-contained.

EDIT: Okay, not-so-small binaries, actually ^^.

[NiLuJe]

@NotANormalNerd: Here goes nothing .

Should be unpacked in / (i.e., like a KoboRoot tarball).

Warning: it'll eat a 10MB chunk of space in the rootfs, because git is a multi-call binary, and we can't have symlinks in the userstore, and I really don't want thirty copies of git for each subcommand .
I tried a mixed approach, but it didn't quite work for everything, so, there.

It should be setup to expect terrible & crappy things (i.e., vfat, no symlinks, terrible fs performance, crappy libc, no iconv, ...), so it *should* behave mostly okay, given the terrible conditions it's going to run in.

Things I could salvage:

* Most of those terrible conditions as stated above, thanks to git's many wonderful compatibility knobs .
* Feeding it a real shell (ZSH)
* Feeding it a real editor (nano)

Things I couldn't salvage (non-exhaustive):

* Feeding it a real pager (nano -v "works", but doesn't actually allow paging in this context, for some reason, which kind of defeats the purpose). Meaning you end up with the default crappy/old busybox less, which doesn't quite understand what's happening to it, but sorta works.

EDIT: Meh, not the first time bb's less has annoyed me. Let's ship the real deal.

EDIT²: less & libpcre2 will move to the main package on next rebuild. Can't symlink less so as not to break stock symlinks, but the ZSH config will be updated to use it.

(Speaking of, in the meantime, unset PAGER (or fix it) to have a shiny less in git).

EDIT³: less & pager issues fixed in current rebuilds.

----

EDIT⁴: The package has now been moved to a proper KoboStuff module.

[NotANormalNerd]

@NiLuJe You are amazing.

Since I am mostly only gonna do a (git pull) on the Kobo Touch (What else are you gonna do with a single 700Mhz Core. It's not like I am trying to run a Kubernetes Cluster on that thing ^^) I think the caveats are fine for me.

I only use the Kobo for the Display. ^^ So I have around 1 GB on the rootfs, which should be very fine.

I owe you a Pizza. Send me a PM.

Best regards,

Dennis

[NiLuJe]

Nitpicking:

Originally Posted by NotANormalNerd

I have around 1 GB on the rootfs

Unless you tweaked the partition layout, no you don't (e.g., I have around ~75MB free in there on an H2O) .

I *really* meant the rootfs, not the USBMS partition .

[NotANormalNerd]

Ah yes, sorry, you are right. ^^

[root@kobo ~]# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root               236.4M    193.7M     42.7M  82% /
none                     16.0M    480.0K     15.5M   3% /tmp
none                    125.1M      4.0K    125.1M   0% /dev
none                     16.0K      4.0K     12.0K  25% /var/lib
none                     16.0K         0     16.0K   0% /var/log
none                    128.0K     24.0K    104.0K  19% /var/run
/dev/mmcblk0p3            1.4G    257.4M      1.1G  18% /mnt/onboard
[root@kobo ~]#

Seems like I have 42 Megs left. Should be plenty for my purposes.

[NiLuJe]

Okay, packages updated .

As promised, less is now available! (I also updated the git package posted earlier to avoid duplicates).

A possibly to-be-reverted change: I mangled dropbear to force logins to ZSH instead of the awful ash version shipped on Kobo.
It might be a problem because it lives in onboard...
In which case, I have another option waiting in the wing, which is to use the ash from my own busybox build that's installed in the rootfs.

(That whole thing was sparked from an annoying issue I have where scp processes spawned by sh -c via dropbear were sometimes deadlocking for no apparent reason... I smelled stdio buffering issues, so I figured I'd try something else).

Speaking of said busybox build, it's now full-featured, standalone, with all the bells and whistles. While in ZSH, it is put in front of the PATH, so most tools will now behave slightly less terribly. If you actually run that ash version (i.e., exec ash), you won't even need it in the PATH, bb is setup in the fancy nofork & prefer applets mode.
As a reminder, that ash build is the only way to have functional unicode input, because everything is terrible.

Warning: if you test shell scripts interactively, that means I strongly urge you to do so from the crap stock shell directly (/bin/sh), with a clean env. Just in case old busybox & friends choke on some stuff that's handled just fine by new busybox & friends, which is quite likely.

[KristianR]

Thanks a lot for this amazing tool-box. Chapeau.

Just one question regarding updating: just install over the other version or is a prior uninstall recommended? I would be updating from r17015.

In case of uninstall/install-cycle one would need the uninstall-script of the prior version?

Kind regards
KristianR

[NiLuJe]

@KristianR: A reinstall works just fine .

If you want to clear up some potential cruft, you can remove /mnt/onboard/.niluje/python & /mnt/onboard/.niluje/python3 *before* the update, as some third-party modules might get updated, but even if multiple copies are left, it's harmless, the versioning scheme will do the right thing .

[NiLuJe]

Okay, as promised earlier, went back to forcing busybox ash (but our own, with a slightly cleaned up profile) as the SSH shell.

Tweaked some various stuff in order to deal with the scp softlock mentioned earlier (it's indeed stuck in a poll, as shown by strace. It also showed that sending a signal broke the deadlock, yay).

If all else fails, I've made preparations to allow switching from dropbear to OpenSSH (c.f., http://trac.ak-team.com/trac/browser...daemons.sh#L21)

Oh, and finally documented how to compile a set of UTF-8 locales, because broken Unicode outside of busybox was severely pissing me off (c.f., the tail end of the README).

[NiLuJe]

Okay, finally got to the bottom of the weird scp stalls.

Turned out to be a weird OpenSSL quirk brought on by the truly terrible kernel & glibc versions we're using...

Tweaked a few shell related things (most prominently, getting rid of the fugly blank hostname in a few places, without actually modifying said hostname), and cleaned up up the sshd/telnet startup script, fixing a nasty issue with broken pidfiles those last few days (which would allow spawning multiple instances of inetd, which wasn't great, but mostly harmless, and could only ever happen if you hot restarted nickel).