Discussions about state of optional migration from Turris 3.x for advanced users

[Sky]

For me it was as easy as this:

    wget https://repo.turris.cz/hbs/medkit/turris1x-medkit-latest.tar.gz
    schnapps import -f turris1x-medkit-*.tar.gz
    schnapps rollback factory
    reboot

No issues and no hassle (apart from reconfiguring using factory setup instructions)

If you have to do it manually you are testing an experimental feature no matter the product it is still in dev and is not guaranteed to work. (There is nothing that forces CZ.NIC to not have the feature experimental for years especially on an hardware that was given for 1CZK at first and is technically “obsolete” as it is not sold anywhere commercially.)

If your post is for Omnia i cannot give you my point of view, but downloading the latest medkit and using its factory should work too .

[jada4p]

It was for Omnia

[Pepe]

@jada4p

As to sensors/collectd, is there any more thorough explanation/guide/etc?

Take a look at OpenWrt’s documentation or you can take a look at collectd’s documentation.

@jada4p

Please note: For LXC Containers you need a custom OpenWrt image.
The image should include at least support for “kernel cgroups’, ‘kernel namespaces’ and ‘miscellaneous LXC related options’ plus ‘kmod-veth’ for optional network support.”

That’s not an error message, I’d say. Just be sure that you have these installed. If you are using the LXC package list from reForis, then these are installed. LuCI does not check if these are installed or not. It just shows it, no matter what.

@jada4p

As to Ludus, would it be re-introduced into OS v5?

Thank you for your question. I added the response regarding it in Ludus’s thread to make it more clear and searchable.

@jada4p

As to HaaS, I don’t see any data even though I allowed it in reForis and logged of HaaS web page and later removed old instance of my TO from it and created new one.

This is a little bit different from Turris OS 3.x.
It is not done automatically from project.turris.cz as you are used to, which is only for our old data collection system. You need to add the HaaS token manually according to the documentation. In Turris OS 5.2.0, which is in HBT, it will be easier and more user-friendly as there is a dedicated tab in reForis, where you will copy&paste the token from Honeypot as a Service website.

[jada4p]

Thanks a lot for your advices, they helped a lot!

I’ll have a look at suggested documentation as to sensors and collectd.

As to containers, I have to apologize for being inattentive, I mistook warning in LuCI container page heading for error message Later I created Ubuntu and Debian containers without problems and they are both working.

Anyhow, there was small problem (regarding both of them) with time (timezone). After some searching I found answer how to solve it in Ubuntu documentation and added notice to an old forum discussion about this problem. TL;DR one should isssue command sudo dpkg-reconfigure tzdata in CLI

HaaS is now OK and working.

As to RIPE Atlas probe Current Status info says: Your probe is currently disconnected. As far I wasn’t able to find how to reconnect it, I asked advice from Ripe support.

Ludus - RIP

[jada4p]

RIPE Atlas probe:

After some time (delay caused by communication problems) I got following advice from RIPE support:

Anyway, we don’t support Turris Omnia as an official platform yet but my guess would be that after the update, your probe got a different SSH key so you need to make sure the key attached to the probe on your account is the same as the one on the actual probe.
You can update your key on your own probe status page on the Atlas website via de tab: Update Public Key.

Thus I generated new SSH key (according documentation: docs.turris.cz/basics/apps/atlas) and changed the key on RIPE Atlas page for my probe…

Thus, RIPE Atlas probe disconnected status is solved.

[viktor]

Discussion is over.

Automatic migration is here!